Agile PM/Development/QA
Daily Scrum is not for activity reporting
Sometimes on a new team, I've seen team members treat the daily Scrum as a place to account for their time and daily activity. This is especially true for members who are on a team part time. They end up going through all their activities for the prior day, instead of concentrating on reporting accomplishments and issues. They discuss what they did on the other team, issues with their hardware, etc. While some of this information may be useful in the sense that it may take away time from what needs to be done in this sprint, it's usually sufficient to mention that some of the time was eaten up by unrelated tasks, rather than go through the whole list of justifying their job.
To some degree this may be the culture of the organization or the environment created by the team or the ScrumMaster. People may feel the need to account for their time. However, it doesn't add any value to the daily Scrum and uses up valuable time.
One of my favorite quotes is "Do not confuse activity with progress". Don't discuss activity during the daily Scrum. Report on progress (or lack of it) and any issues that may affect it.
Posted on Jul 22, 2011 by Gene Mitelman
Agile Development Practices East 2011
November 6-11, 2011 in Orlando, FL
More info and to register, click here.
Posted on Jul 22, 2011 by Gene Mitelman
Agile Development Practices East 2011
November 6-11, 2011 in Orlando, FL
More info and to register, click here.
Posted on Jul 22, 2011 by Gene Mitelman
ScrumMaster and the daily Scrum
For daily Scrum to serve its purpose, the ScrumMaster must truly understand what their role in it is. I've seen new ScrumMasters go through the motions of asking each team member the three standard questions without much understanding as to what to do with the answers. The meeting turns into each person talking about what they did, what they will do, and once in a while reporting an obvious obstacle. Team members end up seeing the daily Scrum as a waste of time. But the worst part is that often the sprint falls short of expectations and it comes as a complete surprise to the ScrumMaster.
What's usually missing in those cases is the desire (or maybe ability) of the ScrumMaster to listen for the hidden cues in what the team members are reporting. There are many reasons why this information is not freely offered up by the team members. Some of them are:
reluctance to admit mistakes
desire to keep peace on the team and not create uncomfortable situations
indifference as to the outcome of the project
simply not seeing/understanding an obstacle or issue
Those cues should trigger some followup on the part of the ScrumMaster, unless other team members pick up on them. What are some of those cues?
Team member keeps reporting working on the same task day after day. The fact that something is wrong should be easily picked up by ScrumMaster, but in reality it not always is.
Team member's report is very vague and high level (ex. "working on reports" or "developing customer portal"). This information is completely useless - it provides no insight into what's actually happening on the project and whether things are moving along or are at a standstill. One of the ways to address it is to break up the stories into more details and ensure that reports are tied directly to those stories. Or the ScrumMaster has to dig deeper on those during the meeting.
One team member briefly mentions that they are waiting on something from another team member (or an external entity) during their report, but don't report it as an obstacle. That's a definite flag that the ScrumMaster should dig deeper to see if there is a hidden obstacle there.
The bottom line - ScrumMaster's job is not just to review/maintain a burndown chart and write progress reports for management. Their role is to monitor team's progress throughout the sprint and intervene when they sense issues, not just when someone asks them to. That takes desire to be proactive, skills, practice, and intuition. But the payback is full understanding where the project is going at any point in time and ability to see failures before they fully realize, so something can be done to prevent disaster.
Posted on Jul 22, 2011 by Gene Mitelman
Agile 2011
August 8-12 in Salt Lake City, UT
More info and to register, click here.
Posted on Mar 23, 2011 by Gene Mitelman
Good overview of various agile/lean approaches
Click here to read.
Posted on Jan 18, 2011 by Gene Mitelman
ScrumMaster beware
A very short article on what happens to some ScrumMasters with lack of management support.
Posted on Nov 18, 2010 by Gene Mitelman
ScrumMaster's job
Scrum emphasizes that a ScrumMaster's job is very different from a traditional PM. The intent is to empower the team to make its own decisions and commitments, leading to significantly better results. Therefore, a ScrumMaster is not an instrument of command-and-control, but rather a supporter/facilitator, whose job is to guide the team and remove impediments.
This is a somewhat simplified view and from my perspective, shouldn't be taken in isolation, especially in environments new to Scrum. There will be a fair amount resistance from the team, product owner, and other groups with whom the team interacts (such as database and infrastructure support, and other teams on related projects). This resistance will rear its ugly head in different ways, varying from outright defiance to passive-aggressive sabotage.
If a ScrumMaster blindly follows the principle of being a facilitator, a power vacuum will form. Since vacuum is not natural, it will be filled by those resisting change. The result will likely be failure on the project, giving those same people who sabotaged it in the first place more ammunition in fighting change.
I argue that a ScrumMaster must follow the concept of "yin and yang", in that they must be soft in guiding and supporting the team on the project, but be brutal in enforcing the process and rooting out negativity (i.e. remove impediments within the team, not just the project). It's somewhat paradoxical, but I believe that hard-line on enforcing the process ultimately leads to team empowerment.
Posted on Oct 14, 2010 by Gene Mitelman
Helping groups agree on plan of action
A short writeup with some ideas on how to help teams reach consensus.
Posted on Oct 04, 2010 by Gene Mitelman
How multi-tasking affects productivity
Ever wonder why some developers seem to be getting things done all the time, while others don't accomplish much? Clearly, everyone has different degrees of knowledge and experience with certain technologies, industries, and subject areas. However, some developers jump into a new area (technologically and/or subject-wise) and start producing usable code right away. At the same time, some others, who have spent years using the same technology and working in the same company (or at least industry), take forever to get anything done.
While not the only reason, I believe that how focused a person is on their work makes a huge difference in their productivity. And I'm not talking about ignoring your job duties, and instead spending hours browsing the Internet. You can be actively working 8 hours a day, and still not produce anything useful. What I am talking about is multi-tasking.
Say you have 5 deliverables due (let's assume each will take you 2 days to complete). You can approach them in different ways. Some people will start on several at the same time. Others may start one, but as pressure is applied, start switching to others. While they are technically making progress on each of the tasks, it may take about 10 days to see any results, since nothing is being completed. Add to that the cost of context-switching, and it may be even longer.
On the other hand, some developers will stay sharply focused on one task at a time, regardless of outside pressures. In that case, their first result will be available in 2 days, next in 2 more, etc. That's a very big difference. Kanban tries to force this approach by putting limits on work-in-process items.
Now, clearly priorities change in business and you can't ignore that. However, people who are consistently productive strike a good balance between accommodating changing needs and working on one thing at a time. One of my favorite phrases is "Do not confuse activity with progress". If you stay focused on one task at a time and avoid the pressure to multi-task, this phrase will most likely not apply to you.
Posted on Sep 23, 2010 by Gene Mitelman
Releasing early and often
Agile approaches, such as Scrum, call for fixed-length iterations. These apply to actually building the software, not so much releasing it. If you look at Kanban, iterations are completely gone, so there is no specific expectation as to how often the software gets released to users at all.
People who have been doing agile for some period of time, know that while the process does not explicitly tell us how often to release the software, it's always best to do so as often as possible. Several reasons are often mentioned, such as getting user feedback from the field (helping to shape the software) and starting to derive value from investment (Lean is big on this). Today, I want to mention another reason you want to release early and often.
Let's take a scenario from my recent experience. We had to implement some major structural changes to a system that was written years ago and our team have been supporting for the last two years. The changes took about two months to implement. We managed to mostly keep other requests for changes from creeping in. These changes were pretty big, so stakeholders were cautious of deploying them into production too soon. As they were dragging their feet on allowing deployment into production, we started implementing newly requested features. The further it went, the more features were added, causing even more apprehension on behalf of the stakeholders. I knew it will eventually come to a head - and it did when two months later some of the newly added features were needed in production, but couldn't be deployed. This finally forced the stakeholders to commit to doing thorough UAT and scheduling deployment in a timely fashion. In the meantime, we've had some tension between users and the team because of not being able to get needed features out. And needless to say, there's been a fair amount of stress due to big-bang deployment instead of steady release schedule.
What I'm talking about here is FEAR. Once changes are perceived as being pretty big, everyone (including the team and the stakeholders) starts getting nervous about releasing them. Common response to this fear is to delay deployment. However, that is completely counter-productive. The further you go, the bigger the changes, the greater the fear. You don't want to get to the point where it paralyses the team into inaction. The solution is to deploy as early as you can, without compounding the fear of the consequences. I've heard the saying "if you're gonna eat a frog, you might as well eat it right away, because it ain't getting any prettier". I full-heartedly agree with this advice.
Posted on Sep 03, 2010 by Gene Mitelman
Intelligent Disobedience makes Great PMs?
A good article on some of the things a project manager must do to be truly great. While not specifically about agility, it does cover an important topic that most people would rather avoid (especially in unforgiving environments).
Posted on Aug 25, 2010 by Gene Mitelman
On optimizing the whole
Recently, I worked on a project that required us to access vendor's software via API. Before starting the project we agreed on two interface points with the vendor - one at the beginning of the workflow on the front-end and one towards the end on the server.
While waiting for the vendor to get their pieces done, we started implementing the UI that would allow us to demonstrate the flow to the client and start getting some feedback. I was looking forward to the completion of the first interface piece by the vendor, so we can finish implementing the start of the workflow.
Two weeks later, the vendor completed the first interface point. To my dismay, it turned out that they implemented the second part first. So we had to continue waiting for the other piece of functionality, before proceeding with our development efforts.
Unfortunately, I didn't specify that we wanted the two pieces of functionality done in a specific order, since we needed them both to complete the project. I just assumed that they would be done in the order of the workflow, so I had noone to blame, but myself.
I'm sure it made sense to the vendor to do things in this order. Of course, from the perspective of the overall project, it would be much more efficient for them to deliver this functionality in the order that would support our efforts. We could deliver the project sooner and more efficiently. That's what the Lean approach concentrates on.
Of course, various agile approaches already give you a tool to help you do that - communication. When you're responsible for delivering functionality (even in the same iteration or sprint) - talk to the people who need it to see if having it delivered in a certain order will optimize overall project delivery.
Posted on Aug 23, 2010 by Gene Mitelman