Hello All,
In the first two parts of this series, we discussed six of Jim Dempsey’s lessons learned in building an Agile software development program. You can review these in the previous blog posts:
In this post, we will focus on the next four lessons learned in adopting an Agile-Scrum. These next four lessons are:
- The Sprint Planning Meeting Will Make or Break the Project
- Manual Tools Work Great
- Requirements Are Still Important
- People Are More Important than Process and Tools
Lesson 7 – The Sprint Planning Meeting will Make or Break the Project. Setting up your Sprints is so critical to the project. How you move things from the Product Backlog and into a Sprint Plan will either solidify your success or make it difficult to attain the objectives of the current Sprint. Some rules of thumb that Mr. Dempsey has found helpful making sure your Sprint planning is as effective as possible are as follows:
o Make sure your Product Backlog is in good shape prior to having your Sprint planning meeting. This means that you need to make sure that it has been properly prioritized by the Product Owner
o As you move features off of the Product backlog onto the Sprint backlog, make sure that the features are small enough to be completed in a single iteration. That means that some features may need to be split into smaller features that you can show value at the end of the Sprint.
o Sprint durations can really be of any length that the team decides is best for a project. Some like 2-week Sprints, others, 30-day Sprints and yet others may want them even smaller. Jim recommends that when you are starting out with Agile, you should consider 30-day Sprints until you have established some “Sprint success.” This time frame is long enough that the team is not scrambling to complete the Sprint, yet short enough to see results often and early.
Lesson 8 – Manual Tools Work Great. If you are enamored with technology, you may find it difficult to resort to using index cards, magic markers and sticky notes to plan and track your projects. But these are proving to be extremely effective in the Scrum team room. Peter Stevens (Scrum Breakfast Blog) discusses Michael Dubakov’s Agile Tools Decision Matrix in his blog article Managing Scrum: The Right Tool for the Job. Michael calls manual tools “Tangible Tools” and states that:
“Tangible tools are great for learning the processes and principles. Hung on the wall, they radiate information for all to see. They are extremely flexible for structuring and displaying information. Use them to get started with Scrum. Use them as long as you are happy with them.”
Jim Dempsey points out, however, that with distributed Scrum teams, you may have to rely more and more on automated tools and techniques. There are many excellent open-source and commercial Agile project management tools available. AgileScout recently posted a blog “Top Agile and Scrum Tools, Which One is Best? , that lists several packages. There are so many out today. Just Google “Scrum Tools” and you will be given the old “fire hose” of data.
Lesson 9 – Requirements are Still Important. When you decided to adopt Agile, did you think that you could just forget about requirements? The Business Analyst did not vaporize overnight. He and she are alive and well, and a crucial part of the Scrum. And it is not a matter of whether we create and elaborate requirements. It is more a matter of how and when do we create and elaborate them. In the old days, they had to all be buttoned up and approved before we could start anything else. In Agile, we move from feature statement to requirement only when we pull that feature from the Product Backlog and into a Sprint Backlog. And it is only then that this requirement gets elaborated. That’s right…think lean…think “Just In Time.” Let’s not forget that Agile’s (and Scrum’s) roots are deeply seated in lean thinking and lean strategies. And Agile requirements can take several forms including:
- User stories
- Use cases
- Flow diagrams
- Wireframes
So keep your business analysts happy. You need them to be successful.
Lesson 10 – People are More Important that Processes and Tools. Do we really need to restate this? YES. There is no silver bullet out there yet, and I would venture to guess that there will not be anytime soon. Project success depends on bringing good people together in an environment rich with collaborative energy where innovation, freedom of expression, respect for others opinions and talents, honesty and trust are rewarded. Invest in the teams and people because in the end they are what make you successful.
In Part 4 of this series, we will discuss the next 4 Lessons Learned in Agile Adoption:
- Don’t Matrix People Across Different Projects
- Focus on Architecture in the Early Sprints
- Re-Estimate Product Backlog Items Every Few Sprints
- Don’t Forget Engineering!
Stay Tuned,
Pete
