How We Can Make Agile Work

I just read a really good post at PM Hut titled Agile Myths Debunked.  Sanjeev Singh listed 12 reasons people say Agile won't work on their projects and how they are misinformed.  His list included:Indiscipline, lack of planning, no documentation, no QA involvement, not for fixed bid projects... and the list goes on.

From my experience, organizations commonly get caught up in their project management processes.  I think they fail to realize, when saying they can not use Agile, the goal is to deliver value to the customer. As professionals, we should focus more on how it can work and less on why it can not.  I do believe Sanjeev's listed myths are the primary reasons Agile isn’t more broadly adopted in some markets.  I’ve sat in meetings and heard those same myths listed as though being read directly from his blog post. Only by educating clients and debunking these myths will we see more adoption.  I'm not saying Agile will work in every circumstance for every project.  What I am saying is you should never discount something unless you've at least tried.  Do your research and see where you can make it work.

Mike Cottmeyer talks about scaling Scrum

On our current project, we have over 100 people across 14 Scrum teams.  The challenge?  How do you communicate between Scrum teams?  Well, that all depends. What are the dependencies between the teams? Though I could write a 1000+ word post about this, I figured I would just link to a short but informative video.  In it, you'll see Mike Cottmeyer talk about scaling Scrum and how you might have different types of scrum-of-scrums (the way you would communicate between Scrum teams).  Mike is a Product Consultant and Agile Evangelist at VersionOne.  You can read more from Mike on his blog, Leading Agile, or on the VersionOne blog, Agile Chronicles. I'm hoping if all goes well, we'll be bringing Mike to Washington DC to offer a few days of training.  I'm sure this will be one of the many important topics to cover.

How To Know When A Meeting Has Ended

I just read are very intriguing post by Ken Clyne on the Agile Blog, located at RallyDev.com. The post was about how problems can arise when people don't realize a meeting is over.  Ken offered one way to avoid the never-ending meeting is by having a clear signal that the meeting has ended. I could not agree more. Don't you just hate it when a meeting has ended, not everyone knows, and people just start to filter out of the area?  I've found myself looking at the meeting host and actually ask if we were done.  That is not a way to conduct a meeting.

Though I believe this applies to all meetings, the daily stand-up (daily scrum) really needs to have a clear beginning and end.  Though some may not agree with me, I like to use a visual aid like a big alarm clock.  Everyone sees the clock ticking away and know a very loud alarm is going to go off at an agreed upon time.  You see people get anxious if others are rambling on and the time is ticking away.  Think back to your youth.  Remember how you knew you were late for class because you heard that starting bell?  Remember how you knew you were dismissed from class because you heard that same bell? Let those years of conditioning motivate the team.  Though I like the visual queue, you should still say something to the team to close the meeting.

Unlike your school days and hearing your assignment is due Monday, I know I've closed meetings with So let it be written, so let it be done, Make it so and May the force be with you.

Link to the original post

Image: Pictofigo

Calculating Initial Velocity On Day Zero

While reviewing proposal documentation yesterday, I noticed the contractor's predicted velocity rate was pretty high.  Being they are not experienced in using Agile and they haven't even started the project, I was curious how they were able to calculate such a high velocity rate for the first iteration.  I know how many developers they intend to use and I know their proposed iteration durations.  I'm not going to get into the specifics as to how they estimated features (user stories, requirements, backlog items, etc.).  So, what did I expect? Velocity is a very simple method for accurately measuring the rate at which teams deliver business value. To calculate velocity, simply add up the estimates of the items successfully delivered in the last sprint or iteration.  What about the initial iteration?

Terms to understand when calculating initial velocity:

1. Number of Developers – How many developers will you have doing actual work?
2. Capacity - What is the maximum amount of work one person can accomplish in an ideal situation during the iteration?
3. Number of Iteration Days – How many work days are in the iteration?
4. Load (Capacity) Factor - The ratio of the actual work output over a period of time and the output if the developer had operated at full capacity over that time period.  e.g. 1/3 = 2.66 Hours , 1/2 = 4 Hours, 1/1 = 8 Hours
5. Velocity - How much Product Backlog value a team can deliver in one iteration.

Because you don’t know team velocity for the first iteration, plan initial velocity at one-third of total capacity in order to account for coffee breaks, design, email, meetings, rework, research, etc.  As an example, with seven (7) developers and at one-third (1/3) capacity, a total of 18.62 development hours are available per day.  Multiply the number by the number of work days in the sprint to arrive at the total of initial work hours.  These work hours will be applied against your estimated items, to arrive at an initial velocity.

(7 [Developers] * 1/3 [Load Capacity Factor]) * 21 [Work Days] = 44.1 [Ideal Work Days]

Ideally, the team should already be formed and stable, so that you can just forecast.  Unfortunately, this whole scenario is faulted. Not only are estimates for team capacity going to vary wildly, but what about the estimates for the deliverables themselves?  I can get pretty good at estimating a level of effort for work that could take a few days.  But the contractor that was noted in this post was estimating a 3-year project.  By the way, if you're curious, the contractor failed within 1 year. The federal agency then exercised their right to not renew their contract for the option years.  The agency then brought in a new contractor with more Agile experience.  

Twitter and a Challenge to Communicate

Twitter allows us to share the time and prevents us from trying to explain how to build the clock.

This morning, Dave Garrett, CEO of Gantthead.com and I were attempting to communicate via Twitter on the topic of PMI and Agile Scrum.

We were both finding it difficult to compress everything we wanted to say into 140 character posts.  I highly doubt Twitter is going to replace the telephone or email as a central method of communications.  It is, however, a great tool to capture the timeline and get your thoughts out quickly to like-minded people.  Regardless of the constraints, it's always good to read Dave's viewpoint or see what he'll post next.  If you want to find an excellent Project Management resource, I recommend you check out and join Gantthead.com.  If you want to see the world from Dave's perspective, minute by minute, I recommend you follow him on Twitter.

140 characters aside, we were able to get our points across to one another.

(Image courtesy of Twitter)

Contribute for the better good

I just posted an update to the Agile Scrum definition on Wikipedia. It has been a while since I've made updates to this definition and others on the free online encyclopedia.  It's actually quite cathartic to contribute to something like Wikipedia, for no other reason then to help others.  I've been asked a lot of questions recently about Agile Scrum and its applicability to my current project.  Though I'm happy that people value my opinion, I figured it was time I revisited Wikipedia and make sure the items I've edited in the past still pass muster.  Sure enough, without telling anyone that I am one of the contributors, I've received two  emails linking to the Wikipedia definitions with notes like "You should check this out".   I hope by continuing to make contributions and updates to publicly available PM related topics, people will be exposed to my work if they know it or not. Have a great day and feel free to leave a comment!

Regards, Derek

(Image by drewpreston on flickr)

Understanding Agile Scrum and common terms

I've been in a few meetings this last week where people were mentioning Scrum terms but didn't know what they were. It's not their fault. The person introducing the terms into the project vocabulary should have provided an explanation before referencing them.

For those of you new to Agile Scrum, here are a few basics:

What is Agile Scrum? There are many specific agile development methods. Most promote development iterations, teamwork, collaboration, and process adaptability throughout the lifecycle of the project.  Agile methods choose to do things in small increments with minimal planning, rather than long-term detailed planning.  There is a heavy emphasis on face-to-face communication over written communication.

Agile Scrum is not ideal for every project.  If the project has high criticality, is using junior developers, has clearly established requirements that do not change often, employs a large number of developers, you should think twice about using it as your method of choice.

I've seen it work very well with small (5-9 member) teams, where all the stakeholder knew they wanted "something" within a short period of time.  They did not know specifically what it was nor how to get from start to finish.  We used a lot of wireframes and prototypes to get us in the ballpark, until we could lock down clear functional and design requirements.

I think it's important for people to understand key terms in Agile Scrum as they relate to other project management methodologies.

Roles

Product Owner The person responsible for maintaining the Product Backlog by representing the interests of the stakeholders.  This owner could be a project manager, director...  Whatever their title, they must have the authority to make decisions on behalf of the project.

ScrumMaster The person responsible for the Scrum process, making sure it is used correctly and maximizes its benefits.  This is NOT a project manager.  This person is a facilitator.  They are merely there as a communications bridge and to offer motivation or remove impediments.

Team A cross-functional group of people responsible for managing itself to develop the product.  This is a small team (5-9) consisting of at least one person from each area (BA, QA, Risk, CM, Software Engineering...)  This team traditionally sits in the same room or area.

Scrum Team Product Owner, ScrumMaster and Team.  Everyone directly involved in the project, with the exception of users, stakeholders, and managers.

Artifacts

Sprint burn down chart Daily progress for a Sprint over the sprint's duration.  This chart can replace a Gantt chart in illustration of progress.

Product backlog A prioritized list of high level deliverables assigned to teams.  This list is similar to milestone deliveries you'd find in a Work Breakdown Structure.  These deliverables will still need to be decomposed (in the sprint backlog).

Sprint backlog A list of tasks to be completed during the sprint and assigned to individuals.  These are the actual decomposed items from the product backlog.  This list must be agreed to by the entire team prior to the sprint actually beginning.  If there is a change in the scope of the sprint backlog during a sprint, the sprint must be immediately stopped and scope redefined.

Other

Sprint A time period (typically between 2 weeks and 1 month) in which development occurs on a set of backlog items that the Team has committed to.  Sprint time periods are established to provide enough time to deliver something, get feedback, and begin another iteration.

Product An output requested by the customer.  It is a completed document, process, web page, database...  Regardless of what it is, the customer believes that it has value.

Other terms to be listed in a later post: Sashimi, timebox, daily scrum, chickens, pigs, retrospective, user stories...