January 3, 2012
Members of my company‘s consulting team recently went on site at a medium-sized financial organization to take a look at how well they were doing Scrum, and provide a path for improvement. They conducted this in the context of a formal Agile Assessment. I thought the approach was interesting, and it might be useful to share it here. The team conducted interviews and made observations in 5 unique areas –
• 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.
December 20, 2011
Michael James just posted his Introduction to Scrum video on YouTube. I’d be interested in your views and feedback.
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.
December 12, 2011
Interesting question from a customer last week as we were discussing continuous integration and testing: Isn’t it likely that someone writing poor code might also write poor and ineffective tests?
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.
November 9, 2011
Many organizations that adopt Scrum focus so much on the iterative nature of agile development that long range vision and strategic product design can get lost. Jimi Fosdick will hold a webinar on November 28 2011 to discuss the need to include long term product vision, coherent user experience and User Centered design and architecture along with specific best practices for achieving a coherent product that delights users.
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:
November 19, 2010
The Agile Scout blog has put out a call for comments on The State of Agile. Ten commentators were invited to contribute. Their musings are being posted on an ongoing basis, starting from the 26th of October. Contributors were asked the following questions:
• What is your background?
• How has Agile changed in terms of methods, philosophies, ideologies, etc
• Where is Agile going in the future?
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/
September 15, 2010
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 (http://www.danube.com/company/bios/michael) Article can be found at: http://www.sendspace.com/pro/dl/vzocgh
June 4, 2010
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.
March 17, 2010
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.”
September 4, 2009
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.
August 12, 2009
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.