Agile Project Management includes different subjects and many Agile and Scrum practices as well, but we will discuss here several major topics.
Measuring Business Value
For stakeholders and managers, the single most appealing aspect about project management with Scrum is almost always the fact that all development efforts are driven by Business Value.
That means that work is prioritized based on the amount of value it will generate for the organization. In an article called “Estimating Business Value,” InfoQ’s Chris Sims considers how teams can determine which user stories represent the highest Business Value. What ensues is a comprehensive discussion of how organizations do just that.
Perhaps most interesting is Pascal Van Cauwenberghe’s assertion that Product Owners should not select user stories they believe to contain the most business value, but should first consider what generates business value and then work backwards to write the user story accordingly.
He offers a step-by-step process to guide Product Owners through that process for the first time:
“We first decide what values (or benefits) we want to achieve before launching a project or product
“Then we find and improve the business processes that deliver that value
“Then we find and improve the supporting business processes that make the value-delivering processes possible
“When the team needs user stories, we take the highest value processes and break them down into user stories at the right level of granularity for the team’s needs. The team pulls the stories, so we only generate a minimal set of user stories.”
The article continues with additional approaches for teams to weigh, including suggestions from Brandon Carlson, Mike Cohn, James Shore, and Kelly Waters. It’s a valuable post for providing so many perspectives to this one problem. To their advice, I’d also recommend consulting Michael James’ whitepaper “An Agile Approach to ‘Metrics’: Applied Macromeasurements to Ensure On-time Delivery” and Dr. Dan Rawsthorne’s whitepaper “Monitoring Scrum Projects with AgileEVM and Earned Business Value (EBV) Metrics.”
Writing Great User Stories
There’s an interesting article on the Scrum Alliance about writing good user stories, requirements and use cases.
According to the writer, user stories are actually narrative texts that describe an interaction of the user and the system, focusing on the value a user gains from the system. A true user story is a metaphor for the work being done. A good user story uses the “INVEST” model:
• Independent. Reduced dependencies = easier to plan.
• Negotiable. Details added via collaboration
• Valuable. Provides value to the customer.
• Estimable. Too big or too vague – not estimable.
• Small. Can be done in less than a week by the team.
• Testable. Good acceptance criteria.
The writer draws interesting comparisons between “traditional requirements”, “use cases” and “user stories” – and the benefits and pitfalls of each. Are user stories better than other types of requirements specifications?
Well it depends. It’s essentially the team that determines whether a particular technique will work or fail. For most scrum teams, the intent of good user stories, however, is to help foster collaboration. If you already have a collaborative team environment and/or are looking to enhance it – read this article for learning more about techniques for writing good user stories.
What HR Doesn’t Know About Scrum
Typically HR practices are rooted in popular misunderstandings of behavioral psychology and what motivates individuals in a work environment. Studies of human motivation reveal typical practices such as micromanagement and performance appraisals are counterproductive in the long run.
When filling Scrum roles, HR departments and hiring managers will often overemphasize credentials and skills and give insufficient weight to the chemistry of the team and letting the team play a key role in the hiring process.
Because Scrum is based on teams that are empowered and self-organizing, oftentimes, employees that appear negative under the restrictions of a forced hierarchy or traditional management can often excel when set free on the right Scrum team because they are often suppressed leaders.
Within organizations using Scrum there can be some confusion as to how people management aspects such as grievance/disciplinary procedures, annual reviews etc should be handled. (See this discussion on Google groups…http://groups.google.com/group/scrumalliance/browse_thread/thread/42c97a2651aa570d) When we refer to Scrum teams as being “self-managing” teams we do not mean that team members can decide to give each other a raise, or fire another team member. This is normally considered an HR or management task.
However, for a Scrum implementation to be successful and for an organization practicing Scrum to be a truly extraordinary organization, there must be a collaboration between HR and Scrum teams when making Scrum organizational decisions.
If you are interested in learning more about HR’s role in the process and how HR can work with Scrum teams to be successful, check out this article by Michael James, a CollabNet Certified Scrum Trainer and Coach
ScrumWorks Pro 4 and Epics
If you work at a large organization where products are developed as constituent parts of over-arching programs, then you know how tricky it can be to track these “shared components.” Well, there’s good news: Danube just published ScrumWorks Pro 4 and its biggest new functionality addresses that very issue. More specifically, the latest release of ScrumWorks includes a feature called “epics” that allows organizations to manage the release of complex projects that include multiple components. This means that the days of brainstorming creative workarounds to achieve similar results are over. Now, users can apply “themes” (a tagging feature for quick searching and filtering) to identify all the PBIs within a given Epic. This gives developers a more intuitive approach to organizing work, while also providing Product Owners and stakeholders with a view of progress that cuts across multiple products. I think you’ll be surprised by how powerful this new feature is. You can watch a screencast here or read more about this release here.
The goal of implementing agile project management
If the goal of implementing agile project management is to boost productivity and yield highly performing teams, then the last thing a manager or Product Owner should do in that environment is stand in the way. And yet, this article on InfoQ describes how managers—out of intimidation, confusion, or both—have a tendency to undermine their best teams. Authors Tom DeMarco and Tim Lister have dubbed this phenomenon “teamicide” and Steven Denning, who has been writing on high-performance teams for InfoQ of late, offers two common management attitudes that can kill a great team:
“Sometimes it’s murder—death by intent to kill: high-performance teams often achieve what they achieve by breaking the rules of the prevailing corporate culture. Managers can feel threatened and so they disband them, in order to preserve the status quo.”
“Sometimes it’s manslaughter—death by negligence: the management doesn’t understand the high-performance team or its mode of operation and so it does things that unintentionally eliminate high-performance, e.g. moving members of a high-performance team to other teams, ostensibly with the goal of creating more high performance teams but typically with the result of eliminating any high performance.”
Have any of you experienced the scenarios described above? I’d be curious to hear if many of you readers have experienced “teamicide” at your organization. And, lest we end on such a negative note, be sure to check out the end of the InfoQ article, which concludes with some great tips from Ominlab Media’s Stefan Gillard for finding individuals who will likely contribute to a high-performance team.
Agile Project Management Dogmas
One of the biggest criticisms against Scrum and agile evangelists is that their all-or-nothing attitude undermines the very improvements Scrum and agile promise. See Agile and Scrum programming. Of course, those of us who do practice by-the-book Scrum and agile understand why it’s so important to hold fast to those principles and processes: because they’re the key to unlocking increased productivity, accelerated cycle time, and reduced overall costs. But in his article “Agile Development: Dogma Vs. Degree,” which recently appeared in the online edition of SD Times, David Rubinstein makes an important distinction that often gets lost in the midst of so much evangelist noise. He writes:
“On one side of the argument are those who believe that adopting any of the steps is a move toward agility; that the important thing is not adherence to the steps but instead an improvement in the organization’s software development.”
What I think is important in this quote is Rubinstein’s articulation that the end goal of adopting agile or Scrum is measurable improvement within the organization, not perfectly complying with every aspect of the methodology’s processes. Again, the “rules” of Scrum and agile are there for a reason: They give teams guiderails to lean on during the difficult process of wide-spread organizational change. But an organization does not win if it adopts every aspect of an agile method. They win when they realize change within the organization and begin to work in ways that lets them do things they never could before.
One note: I found it interesting that Rubinstein decided to interview a representative from every major agile tool vendor except the one that we use! In case you’ve missed it in previous posts, we use Danube’s ScrumWorks Pro to manage our projects and it’s really great—mostly for being so easy to use and aligned with the Scrum framework. If you’re using Scrum and find yourself in the market for a tool, you should definitely look into this one.