I find this short article on burndown chart very informative and easy to understand compared to other articles.
http://www.mitchlacey.com/intro-to-agile/scrum/burndown-charts
The chart (visual) helps the team to see if there is any issue and perhaps can leverage on Kanban's concept of limiting WIPs (work in progress items) to improve the situation.
Sunday, May 17, 2015
Tuesday, June 25, 2013
Common acronyms that may be mentioned in Scrum related materials & notes
INVEST - Independent, Negotiable, Valuable, Estimable, Small, Testable
Details: http://en.wikipedia.org/wiki/INVEST_(mnemonic)
DRY - Don't Repeat Yourself
Details: http://en.wikipedia.org/wiki/Don%27t_repeat_yourself
SOLID - Single responsibility, Open-closed, Liskov substitution, Interface segregation, Dependency inversion
Details: http://en.wikipedia.org/wiki/SOLID_(object-oriented_design)
CI – Continuous Integration
Details: http://en.wikipedia.org/wiki/Continuous_Integration
TDD - Test Driven Development
Details: http://en.wikipedia.org/wiki/Test_Driven_Development
ATDD - Acceptance Test Driven Development
Details: http://testdrivendeveloper.com/2008/04/02/AcceptanceTestDrivenDevelopmentExplained.aspx
DI – Dependency Injection
Details: http://en.wikipedia.org/wiki/Dependency_injection
MMF - Minimum Marketable Feature.
Details: http://en.wikipedia.org/wiki/Incremental_funding_methodology
PBI - Product Backlog Items
Details: http://agilebench.com/blog/the-product-backlog-for-agile-teams
DoD - Definition of Done
Details: http://www.scrumalliance.org/community/articles/2008/september/definition-of-done-a-reference
CFDs - Cumulative Flow Diagrams
Details: http://blog.belatrixsf.com/scrum-cumulative-flow-chart-analysis/
Monday, June 17, 2013
Scrum - Strengths & Challenges
Scrum is a project management framework that is mostly used for software development. It builds upon continuous iteration of predefined processes - planning, development, feedback.
If you search for it, you will get thousands of writings on scrum. I would like to share about what are the pros (strengths) and cons (challenges), and how to deal with the challenges.
Strengths
1. Has built-in communication process - the planning and daily stand-up meetings. This forces and ensures the team is aware of everything that is happening. Continuous communication is key to a project's success.
2. Shippable deliverable. This is really a good one. Most of the time the customer are not really clear of what is needed. But along the way when everyone sees a working product, they can tell if that's what they want or not. This is similar to prototyping. But prototyping can be just on paper or screen design and may not be good enough for customer to see what he/she will eventually get. Thus ship-able products is really a working prototype that customers can use and validate.
3. Scrum expects team members to have multiple skills - design, coding, testing, writing user stories etc. The skills acquired will make a scrum team member to be able to contribute actively in future projects and any kind of discussion. It will also improve their communication skills.
4. Lean product backlog and sprint backlog management. Forced ranking and delaying the detailing of a requirement still we reach it are the 2 methods that I find very useful and believe makes scrum a lean project management framework.
5. Clearly defined user story format :-).
Challenges
1. Meetings are time-boxed. Its good to ensure we are focused. However, there may be more things to discuss and clarify especially during the start of the project or start of a sprint. Limiting time may result in some important discussion & agreements is missed. "After meeting" discussions or unofficial meetings between a few members may result in some members not aware of some of the things.
Possible solution:- I suggest, we use bigger time box in the beginning. Or better still don't time box the first daily meeting. But strive to eventually bring it down to the recommended 15 minutes along the way.
2. It assumes most or all impediments can be resolved in 1 day. What if there are impediments that can't be resolved during that sprint ? It may result in the task or backlog not done. The scrum will be busy but what happens to the developer who took up the task? He/she may end up being "free" as in scrum there is no planning/prioritization during sprint. It assumes all the agreed tasks can be completed during the sprint whether it is a 2 weeks sprint or 1 month sprint.
Possible solution:- I would suggest to have a "stretch goal". That means identifying a few additional items in the sprint backlog. They should be classified as "non-committal". The team should only look at them if for whatever reason they are not able to work on the other committed items. This creates a much more agile situation.
3. In scrum, the Product Owner is the key decision maker with regards to requirements (product backlog) and its prioritization. In scrum, the Product Owner is the ONLY key decision maker on requirements and prioritization. He/She is expected to provide instant answers during sprint planning. But in real scenarios, the Product Owner may just be representing the "requirements team" who is talking to their own customers. Unless the Product Owner has full and complete knowledge of all the requirements, which is a rare case, he/she will not be able to provide accurate and instant answers to the team members. This situation will cause some delays in the team's progress.
Possible solution:- During backlog refinement meeting and sprint planning, Product Owner should be allowed to bring along a few other members. However, their roles should be limited to providing clarification. The Product Owner should still be the decision maker on prioritization. In this way, we can clarify matters faster. After a few sprints, the Product Owner (and the team) will have much better understanding and should be able to clarify and make decisions without the involvement of other members. Of course, in both cases, the Product Owner should continuously engage his/her requirements team to be on top of the requirements and so that he/she should be able provide clarity on the backlogs.
4. Some organizations are very operational in nature. They do not have dedicated project teams working on software development projects. Since operational support is always the number one priority for most organizations, it is going to be very difficult to assign a few members to be spending full time on a software development project as demanded in scrum. Sometimes there is no one who can support a system better than the team member. Sometimes his/her partner may be out on vacation or unplanned/emergency leave.
Possible solution: Having shorter sprint cycles (such as 2 weeks) may actually help. The person can be away for 1 sprint and join back the team in the next sprint after having the issue addressed or his/hear partner back to work. Having shorter sprints can also help in a situation whereby rotation of duties is practiced. However, changing of team members will increase the time for them to familiarize themselves with each other and take longer time to reach the performing stage (based on Tuckman Model).
5. Effort estimation depends on each team members skill set, experience and familiarity with the system. Different estimates may be given due to lack of skill set rather than lack of understanding. Junior team member may be feel uncomfortable providing estimates. Different estimates may also arise if the developers have different approach in mind. Sometimes both approach may have its own pros and cons.
Possible solutions: During estimation, team members should describe not only why they estimate so but also explain briefly how they would develop the solution for the user story. This will help the team to understand why is the estimation being made so.
If you search for it, you will get thousands of writings on scrum. I would like to share about what are the pros (strengths) and cons (challenges), and how to deal with the challenges.
Strengths
1. Has built-in communication process - the planning and daily stand-up meetings. This forces and ensures the team is aware of everything that is happening. Continuous communication is key to a project's success.
2. Shippable deliverable. This is really a good one. Most of the time the customer are not really clear of what is needed. But along the way when everyone sees a working product, they can tell if that's what they want or not. This is similar to prototyping. But prototyping can be just on paper or screen design and may not be good enough for customer to see what he/she will eventually get. Thus ship-able products is really a working prototype that customers can use and validate.
3. Scrum expects team members to have multiple skills - design, coding, testing, writing user stories etc. The skills acquired will make a scrum team member to be able to contribute actively in future projects and any kind of discussion. It will also improve their communication skills.
4. Lean product backlog and sprint backlog management. Forced ranking and delaying the detailing of a requirement still we reach it are the 2 methods that I find very useful and believe makes scrum a lean project management framework.
5. Clearly defined user story format :-).
Challenges
1. Meetings are time-boxed. Its good to ensure we are focused. However, there may be more things to discuss and clarify especially during the start of the project or start of a sprint. Limiting time may result in some important discussion & agreements is missed. "After meeting" discussions or unofficial meetings between a few members may result in some members not aware of some of the things.
Possible solution:- I suggest, we use bigger time box in the beginning. Or better still don't time box the first daily meeting. But strive to eventually bring it down to the recommended 15 minutes along the way.
2. It assumes most or all impediments can be resolved in 1 day. What if there are impediments that can't be resolved during that sprint ? It may result in the task or backlog not done. The scrum will be busy but what happens to the developer who took up the task? He/she may end up being "free" as in scrum there is no planning/prioritization during sprint. It assumes all the agreed tasks can be completed during the sprint whether it is a 2 weeks sprint or 1 month sprint.
Possible solution:- I would suggest to have a "stretch goal". That means identifying a few additional items in the sprint backlog. They should be classified as "non-committal". The team should only look at them if for whatever reason they are not able to work on the other committed items. This creates a much more agile situation.
3. In scrum, the Product Owner is the key decision maker with regards to requirements (product backlog) and its prioritization. In scrum, the Product Owner is the ONLY key decision maker on requirements and prioritization. He/She is expected to provide instant answers during sprint planning. But in real scenarios, the Product Owner may just be representing the "requirements team" who is talking to their own customers. Unless the Product Owner has full and complete knowledge of all the requirements, which is a rare case, he/she will not be able to provide accurate and instant answers to the team members. This situation will cause some delays in the team's progress.
Possible solution:- During backlog refinement meeting and sprint planning, Product Owner should be allowed to bring along a few other members. However, their roles should be limited to providing clarification. The Product Owner should still be the decision maker on prioritization. In this way, we can clarify matters faster. After a few sprints, the Product Owner (and the team) will have much better understanding and should be able to clarify and make decisions without the involvement of other members. Of course, in both cases, the Product Owner should continuously engage his/her requirements team to be on top of the requirements and so that he/she should be able provide clarity on the backlogs.
4. Some organizations are very operational in nature. They do not have dedicated project teams working on software development projects. Since operational support is always the number one priority for most organizations, it is going to be very difficult to assign a few members to be spending full time on a software development project as demanded in scrum. Sometimes there is no one who can support a system better than the team member. Sometimes his/her partner may be out on vacation or unplanned/emergency leave.
Possible solution: Having shorter sprint cycles (such as 2 weeks) may actually help. The person can be away for 1 sprint and join back the team in the next sprint after having the issue addressed or his/hear partner back to work. Having shorter sprints can also help in a situation whereby rotation of duties is practiced. However, changing of team members will increase the time for them to familiarize themselves with each other and take longer time to reach the performing stage (based on Tuckman Model).
5. Effort estimation depends on each team members skill set, experience and familiarity with the system. Different estimates may be given due to lack of skill set rather than lack of understanding. Junior team member may be feel uncomfortable providing estimates. Different estimates may also arise if the developers have different approach in mind. Sometimes both approach may have its own pros and cons.
Possible solutions: During estimation, team members should describe not only why they estimate so but also explain briefly how they would develop the solution for the user story. This will help the team to understand why is the estimation being made so.
Tuesday, June 11, 2013
Videos on Agile Project Management - Scrum with Kanban
Simple but good sharing on the Scrum Framework @ http://www.youtube.com/watch?v=_BWbaZs1M_8
I find this talk @ http://vimeo.com/16918747 very useful to understand what are Scrum and Kanban and how we make use of both for better result. There is also the free e-book @ http://www.infoq.com/minibooks/kanban-scrum-minibook.
Another video below gives a quick comparison between Scrum & Kanban @ http://www.youtube.com/watch?v=Jx6_E5XxqEo
Tuesday, June 4, 2013
Project Management vs Playing Chess
Project Management vs Playing Chess
1. A plan is needed. You need to have a plan (& strategy) on how you want to run the project (which methodology to be used, what are the deliverable, when to to deliver it), play chess (chess strategy what else). B plan is also needed :-).
2. But be alert & flexible - a.k.a be street smart. But quite often, things that are out of our control will happen and disrupt our plan. A team member can leave the project and the opponent can make an unexpected move. It's very important that we are always on alert on whats happening and it is equally important to react fast. We must be flexible to change our plan based on new circumstances to avoid critical delay in the project or loss of a piece or worst still loss of the game.
3. Sunk cost. In business, there is a term called "sunk cost". Sunk cost means the cost that has already occurred and should not be considered for future decision making. Similarly is projects, there can be a deliverable which was identified earlier as needed but later need to be dropped. In chess, we may have sacrificed a piece as part of our strategy but after we realized the strategy won't work, we should not worry about it anymore and should start fresh. In another word, stop carrying the baggage from previous decision that may not be valid moving forward.
4. Stay cool. When the going gets tough, the tough must get going!!.
1. A plan is needed. You need to have a plan (& strategy) on how you want to run the project (which methodology to be used, what are the deliverable, when to to deliver it), play chess (chess strategy what else). B plan is also needed :-).
2. But be alert & flexible - a.k.a be street smart. But quite often, things that are out of our control will happen and disrupt our plan. A team member can leave the project and the opponent can make an unexpected move. It's very important that we are always on alert on whats happening and it is equally important to react fast. We must be flexible to change our plan based on new circumstances to avoid critical delay in the project or loss of a piece or worst still loss of the game.
3. Sunk cost. In business, there is a term called "sunk cost". Sunk cost means the cost that has already occurred and should not be considered for future decision making. Similarly is projects, there can be a deliverable which was identified earlier as needed but later need to be dropped. In chess, we may have sacrificed a piece as part of our strategy but after we realized the strategy won't work, we should not worry about it anymore and should start fresh. In another word, stop carrying the baggage from previous decision that may not be valid moving forward.
4. Stay cool. When the going gets tough, the tough must get going!!.
Subscribe to:
Posts (Atom)
