• Value delivery
• Agile engineering
• Project Management
• Product management
• Environment and Organizational Culture

The investigation also took input on the demographics of the individual project being examined, the stakeholders involved and the competitive/regulatory environment in which the organization as a whole operates. Understanding the context in which an organization operates is crucial to understanding the optimal level of Agility, and thus, the plan of action. Understanding the goals of the organization is particularly important. Not every axis needs to be top-ranked to achieve the company’s goals. In fact, on this particular assessment we found that only one needed urgent attention – Project Management. More on this later.

By the way, the company uses ScrumWorks Pro as its Agile Project Management tool.

This is the first in a Scrum training series which he will post on Youtube (free to you, of course). With regards to this overview, I think is the right length and depth – it’s not so short as to be trite (or worse, incorrect), but it’s not an exhaustive examination of Scrum either. This video is good prep for people who are planning to enter a CSM class and don’t want to go in cold. It is also good for stakeholders around the company who want an understanding of Scrum so that they can work better with their development teams.

Let me know what you think.

My response is “absolutely”. Poor coders are often (maybe not always) poor at writing test cases. The good news is that Agile practices are designed to uncover and highlight issues like this so that they can be addressed. Practices such as Pair Programming, code review, daily stand-ups, retrospectives, and sprint review meetings can help overcome such shortcomings, but at the end of the day, there is no magical fix for poor test writing.

Though traditional project management and Scrum have long been viewed as antithetical ways of working, that’s not quite right. It would be more accurate to say that Scrum simply responds to and refines the shortcomings of traditional management practices. Still, as Scrum and other agile methods have continued to grow in the past few years, many PMPs have begun reassessing Scrum and agile to see what aspects of those methods it can utilize. On the PMI website, they’ve just run a short interview with an individual who straddles both worlds: Jimi Fosdick, who is both a PMP and a CST (certified Scrum trainer). According to him, it’s still possible for traditional project management and Scrum and agile to coexist. Still, he’s quick to point out that there are major challenges. Of those, he cites the following as the most irksome:

“Organizational Structure: Companies aren’t usually set up to handle the way the work is done in scrum and agile–and that’s a very difficult thing to change.

“Corporate Culture: Scrum is built on the principles of self-organization and self-management. So the development team doesn’t really have a boss or a manager telling them what to do. And that’s very scary for a lot of organizations. There’s a prevailing belief–left over from the scientific management of the 1950s and 1960s–that unless you’re watching what your people are doing, they won’t complete the task at hand.

“False Assumptions: Many of the policies and progress metrics in place in organizations and the artifacts and reporting required, are often counterproductive and run contrary to scrum. Some tasks–like needing sign-off on a full requirements document before development can start–interferes with the ability to do something in an agile way.”

You can read more here: http://blogs.pmi.org/blog/voices_on_project_management/2009/12/agile-apprehensions.html

Topics will include:
• Discussion of Product Vision and approaches to crafting a compelling overall vision for products
• Discussion of User-Centered/Value-Driven design and approaches to incorporating user experience (UX) and software architecture early in the development process
• Explanation of the pitfalls of a lack of vision and so-called “hybrid” models for incorporating UX and architecture into Scrum Projects

Register for the session here:

Tobias Mayer had a particularly eloquent response:
“…We are marching, or perhaps more accurately slipping and sliding towards a new paradigm. Agile is part of a ripple that when combined with other ideas and practices will collectively become a tidal wave of change.”
“So how do I see Agile? I see it as one stepping stone (a particularly beautiful one) on a great journey towards a business world that is more caring, loving, respectful and altogether more joyous. Agile will meld into the ideas of many other movements, and we’ll all move forward towards the greater goal, seeking similarities and finding ways to collaborate, innovate and reconceive the way we work.”

Check out the rest of the responses at: http://www.infoq.com/news/2010/10/state-of-agile-blog-series
For more information on Agile and free agile webinars visit http://www.danube.com/scrum/webinars/scrumcore/

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 (http://www.danube.com/company/bios/michael) Article can be found at: http://www.sendspace.com/pro/dl/vzocgh

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.

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.”