Wednesday, January 30, 2013

Should we revisit Scrum’s Product Owner Role ?

This article below I wrote got recently published on Techwell.

image Nearly 52 percent of agile projects are following Scrum or some variant, according to VersionOne’s state of agile development survey. I’m sure that the dollar value of this percent of Scrum projects would run into billions, if not trillions, of dollars. With so many business people betting their money on Scrum, my question to you is “Do organizations have the right set of people lined up to deliver these projects using Scrum?”

A detailed analysis of the roles and responsibilities of an agile project clearly states that the project owner (PO) is responsible for the return on investment (ROI) of the project in addition to being a backlog owner. With POs taking on such an important role on their shoulders, are they really skilled and empowered to do their jobs?

My own personal experience working on several Scrum projects says that POs are used more than anything else for defining, prioritizing, and maintaining the backlog. It’s more of a transactional role between the PO and the team. Many product owners don’t even know the business value of the requirements. 

In typical Scrum projects, the business sponsors allocate the budget and share their vision with an experienced domain expert—the product owner. This domain expert in turn takes help from so called “business analysts” to write the epics and user stories that are shared with the team. The delivery teams work like horses as they churn out code and demo at the end of each Sprint.

I don’t see how the traditional way that Scrum projects are being implemented would produce any ROI to the business in the long run. Delivering ROI depends on more than just delivering the software code and deploying it to production with zero defects. In my view, the success lies in the end customers actually using the product effectively and buying or using more of it.

Some people recommend forming a product owner team that includes business analysts and a marketing and sales team as well. However, I don’t think this is going to solve the ROI problem defined above. I am getting more questions than answers.

Will the world change and will POs be empowered to really drive ROI? Should we separate the ROI responsibilities from the product owner and call them “backlog managers?” Maybe we should look at redefining Scrum roles.

photo credit: laverrue via photopin cc

Wednesday, January 23, 2013

Agile Dev Practices Conference - March 4–7, 2013

Check out the  Agile Dev Practices Conference  in Potsdam by Berlin.   The early bird ends on January 31st. 


Technorati Tags: ,

Tuesday, January 15, 2013

7 Key practices to follow in maintenance projects

One of my earlier articles got republished again on DZone this week and am reposting it below. Check out this article on DZone as well.

image In many Agile training programs and conferences, a common question that gets raised is, does Agile/Scrum work in maintenance projects?
I always say "YES" and the team needs to tweak or invent the practices to suit their needs.
Maintenance projects could be enhancement projects OR pure defect fixing projects.
Enhancement projects involve new set of developments over existing one. Since the developers get a new set of requirements at the end of each iteration, one can apply the standard set of Scrum practices with little or no modification.
Defect Fixing projects involve fixing defects on closed or current projects not in development. Sometimes these projects are boring, especially if a new team has been hired for defect fixing purposes only. The customer sends a set of defects on a daily basis or weekly basis with a deadline to deliver. The development team needs to fix them ASAP and send the patch for further testing.

While coaching one of such a defect fixing projects, I found that the following Scrum practices can be applied without much modification:
1. Daily Scrum meetings
2. A Scrum of Scrum
3. Modeling days while solving complex defects
4. Information radiators displaying InProgress, completed, reopened, closed defects and other information
5. Usage of Wiki for collaborating with the customer
6. Requirement workshop while understanding complex defects
7. Review and Retrospective
A common problem that I have found in defect fixing projects is setting the iteration length. Especially if the defects are given on a day to day basis without prior knowledge of what you are going to get, it makes the life of the development team bit difficult.
This can be solved by collaborating with the customer and coming up with a plan to have 1 or 2 weeks of iteration length.

photo credit: contemplative imaging via photopin cc

Sunday, January 13, 2013

The 4 ingredients of building Hyper Productive teams

The complete article of my guest post on Zephyr  is available below:

image It is every leader’s dream to build hyper productive teams (Hype Team). This topic not only attracts a lot of attention but at the same time leads to a lot of debate as explained in the following paragraphs. I have worked as a team member as well as a leader on several different projects in different geographies. Irrespective of the cultural background of teams, domain or technology being used, my own personal experiences of building hyper productive teams concur with several research papers.

What are Hyper productive or high performance teams?

Let me tell you that there is no formula to specify a team as Hype Team without comparing it to another team. The measure of productivity is always contextual. Wikipedia defines a Hype team as: A group of people with specific roles and complementary talents and skills, aligned with and committed to a common purpose, who consistently show high levels of collaboration and innovation, that produce superior results.

The most popular example of building hyper productive teams in the Scrum world comes from Jeff’s paper on Shock Therapy – boot strap on Hyper productive teams. Jeff defines a Hype Team as follows: We define Hyper-Productivity here at 400% higher velocity than average waterfall team velocity with correspondingly higher quality. The best Scrum teams in the world average 75% gains over the velocity of waterfall teams with much higher quality, customer satisfaction, and developer experience.”

Even though not everyone agrees with the jeff’s definition, my own experience says it is possible to build a passionate, highly energetic, self-organized team by using the following ingredients.

Ingredient 1: Identify a good leader

So far no one has been able to articulate a step by step approach to building Hype Teams. But many have been in successful in capturing the different ingredients needed to build one.  However, I strongly believe that hiring or having a good leader is the first step in building the Hype teams.  Psychology Today provides some good tips in hiring leaders.

Indicators for identifying leadership:

  • Does the person help the team become more effective at making decisions quickly and reaching a working consensus?
  • Does this person foster effective collaboration across a team made up of several experts?
  • Does this person impose discipline on themself and their team to prepare and act with the professionalism?

Ingredient 2: Common goal and shared vision

All research available on the topic of building Hype teams agree on one thing, having a common goal with a clear vision. Building a shared vision is context dependent. In the Agile world, this could include having clarity on the backlog items, common agreement on definition of ready and done checklists, common understanding of what defect means. Are the common high level goals clear to everyone: can individuals abandon their individual objectives and metrics to respond to unfolding situations or do they wait for instruction?

Every major decision should document:

  • How can we tell if this works?
  • When will we know?
  • What will we do if it doesn’t?

If you are struggling to understand your customer’s vision, try this popular game Remember the Future.  Reiterate and share goals/visions as often as possible. This could be done through posting the vision in a visible place, revisiting them during the showcases. The shared vision approach combined with good leadership skills would create Self organizing teams, necessary to nurture high productive teams. Self organizing is possible only if the teams respect each other.

A few questions to ask yourself in regards to building self organizing teams include:

  • Is there an open and free flow of information so that teams can self-organize around problems?
  • How important is for you to be in control: do you prefer inaction to mistakes in the absence of your specific instructions?
  • Are the common high level goals clear to everyone: can individuals abandon their individual objectives and metrics to respond to unfolding situations or do they wait for instruction?

Ingredient 3:  Trust, Trust and Trust

Creating a safe place for the team to express their opinions and creating space for the team to fail. Building a transparent culture and following through the commitment builds trust within the team. Transparent culture can be built by making the data visible through radiators in the team rooms. Let radiators show all the risks, issues and blockers. Move away from the information refrigerator culture. Continuing to be transparent and sharing the bigger picture with the teams the time leads to people to stop working in isolation and in turn creating the foundation for systems thinking culture.  The book “How NASA Builds Mission Critical Teams” provides a detailed view of applying systems thinking concepts in building high performance teams.

I pulled an excerpt from Dr. Atul Gawande’s Failure and Resuce commencement. I think these are three skills that help teams build trust.

  • Judgment: the ability to develop a point of view and to use it to make decisions in a timely fashion as dictated by the implications of unfolding events. This may require making decisions with incomplete information, and that’s a useful distinction  to remember: if you have enough information it’s a choice based on your values, if you don’t, if there are uncertainties or ambiguities, it’s a decision.
  • Mastery of Teamwork: this requires effective two way communication, timely coordination, and establishing a level of trust that enables effective collaboration. It also requires alignment on goals, agreement on roles, negotiation of a common process, and a commitment to effective business relationships.
  • Accepting Responsibility for Consequence of Your Choices: you can make a good decision based on all of the information you have in hand and still have a poor outcome. Sometimes a poor outcome is a possibility that can be anticipated and mitigated and sometimes it’s part of the “unknown unknowns” of a situation.

Ingredient 4: Continuous improvement

High performing teams are not built in a single day or a month. It usually takes a few months to a couple of years. Teams working on long durations need to continuously learn and evolve. This article articulates the importance of continuous learning very well.

Here is another good book Management Challenges for the 21st Century, written by Peter Drucker, address the issue of continuous improvement on the “Change Agents” chapter.

This excerpt elaborates on his core concept of organized abandonment.

For being a change leader requires the willingness and ability to change what is already being done just as much as the ability to do new and different things. It requires policies and practices that make the present create the future.

Abandon yesterday. The first step for a change leader is to free up resources that are committed to maintaining things that no longer contribute to performance and no longer produce results. Maintaining yesterday is always difficult and extremely time-consuming. Maintaining yesterday always commits the institution’s scarcest and most valuable resources–and above all, its ablest people–to non-results. Yet doing anything differently–let alone innovating–always creates unexpected difficulties. It demands leadership by people of high and proven ability. And if those people are committed to maintaining yesterday, they are simply not available to create tomorrow.

Working in distributed mode

The challenges get multiplied while working in a distributed environment. Use of effective communication tools play a key role here.  In the Agile world, the scrum of scrum meetings with key stakeholders from the multiple geographies could help in alleviating the pain a bit. I use Ideaboardz as a tool to conduct distributed retrospective, estimation using planning poker is done using Video conferencing devices.

To summarize, the recipe to build high performing team is based on the above 4 ingredients.  You miss one; the recipe is gone once and for all.

photo credit: 'PixelPlacebo' via photopin cc