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!!.
Thursday, May 30, 2013
Escalate for timely issues resolution
One way to ensure timely completion of pre-defined project tasks is close follow-up. In reality tasks owners may have many tasks to perform simultaneously. Project managers needs to follow-up with them closely.
However, it may not work all the time. The task owner may simply don't have the bandwidth to perform the task. She or he may need to attend to another urgent or higher priority issue (personal or business). As in some cases, the duration planned may not be accurate and the task owner doesn't really have the skill set and expertise he or she is expected to have.
Whatever it is, once a task is not completed on time per plan, then we have an issue here. But how can we ensure the issue does not become chronic and impact the project schedule, cost or quality ? This is where, we need seek help. This is called escalation.
Who do we escalate to ? Depending on the issue at hand, we should escalate to either the program manager, client or project sponsor, partner's management, vendor's management or our own higher management.
When do we escalate ? This will be purely based on project managers judgement. But timely escalating is very important.
To be effective, the person that we escalate to should be provided right level information as what is it that we are escalating about and what kind of help are we seeking from them. The tough part is to ensure our relationship with the task owner is not damaged. This is a challenge because some people can take this personal. However, we also cannot delay escalation because higher management or sponsors hate surprises especially if it negative news. It is better for them to be aware of the current state of the project and not be surprised. In fact escalation should be seen as a healthy way of communication or not healthy to have it done frequently.
Monday, May 27, 2013
Follow-up for a successful project completion.
Communication has been always a key challenge in all most any matter we come across in our daily life. I guess it is because all matters centers around our interaction or relationship with others be it our spouse, colleagues, parents, siblings, friends.
During project management, project plan, task due date, availability ( or unavailability), issues, risks, actions required all need to be communicated to the right party at the right time with the right level of details. If we communicate too early it may be forgotten especially "busy" people who may find it annoying as they are probably chasing after late tasks. If we have these people in the project, its going to be nightmare for the project managers. On the other hand, if you communicate too near to task start date or due date, it becomes "your mistake/problem".
So to handle these situations, we need to communicate frequently a.k.a do close follow-ups
i) Give a tinkle 1 week before to the task owner to ask if she or he will be available to perform the task. If not then we need to source for the replacement. Don't be surprise if people go on leave during the time you need them to perform certain tasks. This happens even in multi-national companies (MNCs) or in projects that have a very clear project plan and senior members.
ii) The follow-up with the task owner 1-2 days before to ask if they have started the work or are ready to perform the task as planned. I am sure you wonder why I ask if they have started the work even before the start date. Some people are actually efficient that usually start work earlier. That's how they manage their time. For those who hasn't start it is kind of a soft reminder for them. Either way it is a win-win situation.
The first 2 above can provide us an idea if there is any risks for that tasks. These issues must be documented, tracked and escalated if needed.
iii) Third follow-up should be done mid-way of the task to gauge the progress. The number of follow-ups depends on how long is a particular task and how comfortable are we with the task owner. If we have good experience with the task owner then we can afford less follow-up with them. Otherwise it is safer to have more frequent follow-ups. We may want to ask for some kind of proofs as well if our level of confidence on the task owner is very less. Some people has a tendency to start work on the due date specially on short tasks that is planned for 1-2 days. Although short tasks, if they are in critical path, then they will cause delay in the project progress. So we need to be very vigilant here. This is also where we have the "right" to get the task owner to work on their tasks.
This 3rd item can provide us an idea if there are any issues for that tasks.
iv) Finally we need to follow-up to know if the task has been completely successfully. Successfully ?? Yes. It means you must have a way to gauge every tasks completion to determine if indeed it can be considered successfully completed. After all, the project manager is responsible for the successful completion of his project and that means successfully completion of each and every the tasks in that project.
Happy project managing !!
Friday, March 29, 2013
Critical Success Criteria for a Project
This is what I think what is extremely important for a project to be successful.
1. Good Communication. This is not new but seems like some projects managers simply don't get it. What does "good communication" means ?
Good communication refers to :-
a) Timely communication. If you report out something that people already heard, then it is of no use and it may even create confusion, unless you are correcting any misinformation that is out there.
b) Accurate information. Whatever we communicate whether verbally, in email or status reports, must have accurate and complete information otherwise recipients will get a wrong picture. Some people are just plain lazy to provide sufficient details.
c) Right level of details to the right recipients. Don't simply copy to all unless requested.
For example, if there is a delay because of something happened (or didn't happen), then we should inform the impacted stakeholders soonest possible and not wait for the daily or weekly report out. The communication should also include what happened, the impact of it to the players and what should or can be done by the impacted persons or task owners. Otherwise, recipients will just read the email and .... (do nothing).
2. Commitment
I find that lack of commitment is another cause for project delays or failure. Or people say they commit but don't really honor that. It may be also due to changes in priority for the person. Or change in direction by the boss.
Only sitting down and discussing with the person will help to address it. If it doesn't help, then follow the escalation chain.
Subscribe to:
Posts (Atom)
