Enterprise Agile: ‘Water – Agile – Fall’ Makes a Splash in New Forrester Report

Tony TimbolIt's safe to say that for Agile practitioners who are working with clients, the recent findings about enterprise Agile in Forrester's "The 2015 State of Agile Development Report” are not all that surprising. For Agile purists the findings may seem discouraging, but in my view, the report shows that Agile’s benefits are so clear, that it is driving change regardless of barriers to adoption.

This quote about enterprise teams struck me specifically, "The teams know how to integrate Agile development with waterfall practices in an overall enterprise governance framework. When done well, Forrester calls this Water-Agile-Fall. 'Done well' means upfront planning and an understanding of very high-level product requirements (water), then sprints kick off with further user stories of refinement, design, development, testing, and integration (Agile), and, lastly, release packaging and deployment (fall).”

The words "upfront planning" and "high-level product requirements" indicate that enterprises are trying to fit Agile into existing organizational lines of command-and-control, as opposed to decentralizing decision making. Change is hard - these types of allowances are expected.

This chart from the report underscores the challenges organizations are facing in full Agile adoption:

Forrester State of Agile 

What's the big takeaway here? Do not underestimate the challenge in moving from a functional line-of-business model to a product/value stream structure, which aligns better with Agile and lean software engineering. This transition brings many organizational, personnel, and financial issues to the forefront that are not so easily addressed.

Even as solid as the SAFe (Scaled Agile Framework) approach is to scaling Agile, enterprises should move deliberately and carefully and understand that scaling is less about technique and more about effective change management.

You can download a copy of the report here.


Tony Timbol
VP of Business Development & SAFe Program Consultant

 

Written by Tony Timbol at 05:00
Categories :

Better Agile & Software Development Presentations

Better Agile conference

Last month Mike Harris and Tom Cagley attended the Better Agile and Software Development East conference. At the Better Software Conference, attendees learn about the latest tools, trends and challenges regarding software development approaches, plan-driven development methods and process improvement programs. The Agile Development Conference is for those seeking more information about Agile practices, processes, technologies and principles.

Tom Cagley, Vice President of Consulting, presented at the Agile track of the conference. His presentation, "Managing Risk in Agile Development: It Isn't Magic!" discussed how the implementation of Agile processes allows you to avoid spending significant time analyzing risks, while making it very difficult for an unseen risk to sneak up on your project.

Mike Harris, CEO, presented at the Better Software track of the conference. His presentation, "Visualization to Improve Value Delivery," provided an overview of the key elements of flow theory and shared five simple but essential metrics—value visualization—for defining and tracking business value.

Both presentations are available for download! Hit "Download" below to receive both of the presentations in one file.

Download

Written by Default at 05:00
Categories :

What is a Product Owner and Why Do I Need One?

Scope of this Report
“The Product Owner is the one and only person responsible for managing the Product Backlog and ensuring the value of the work the team performs. This person maintains the Product Backlog and ensures that it is visible to everyone.” - Ken Schwaber, “Scrum Guide”

Scrum defines three basic roles1 within a Scrum team: developers (including testers), a scrum master/coach and product owner. Each of these roles is critical for delivering value effectively and efficiently. The product owner role is deceptively simple. The product owner is the voice of the customer; a conduit to bring business knowledge into the team. They define what needs to be delivered to support the business (or at least finds out), dynamically provides answers and feedback to the team and prioritize the backlog. From a business perspective, the product owner is the face of the project.
This essay will highlight the role of the product owner and why something that seems so easy is generally the hardest role on an Agile team.

The job description of a product owner is fairly straightforward. Their job is to act as the voice of the customer, prioritize the backlog, answer or get answers to the team’s questions and accept/reject the work that the team generates. However the devil is in the details. Understanding the nuances of applying the role is important to successfully function as part of an Agile team.

The Role: Leader or Drill Sergeant?
A leader directs and coordinates activities based on their vision of the future. In Agile projects the product owner provides their vision to the team what they aren’t is drill sergeants. Leaders also need to ensure that a team’s goals stay undiluted by extraneous priorities. A drill sergeant is colloquially viewed as a micromanager who trains team members by drilling them on exactly how each task is to be accomplished. The role of product owners evolved out of the roles of project manager, business subject matter expert (SME) and project sponsor from the waterfall environment. In the waterfall model of projects, each of these roles provided different levels of direction, management and leadership. The project manager is the administrator. The SME provides information on what is done today and what they will need in the future. The sponsor’s role includes providing resources, framing the scope of the project, providing direction as the project moves forward and to demand that the project delivers. The sponsor and the project manager are generally the outsiders that exhort the team into action . . . they act as drill sergeants. While classic project management techniques often include a role similar to a drill sergeant, Scrum and other Agile frameworks actively eschew this role. The Agile principle that states that “the business and developers must work together daily” suggests shedding the approach of an outsider exhorting the team, and implementing the concept of the product owner as leader within the team.

In an Agile project the product owner’s roles include:

  • Owning and prioritizing the product backlog,
  • Providing product vision2,
  • Involving customers, users, and other stakeholders, and
  • Collaborating with others on the team.

The qualities of a product owner are very different from the attributes of the screaming stereotypical drill sergeant. The most critical behavior is often collaboration with others in the business and with the development team: the act of working together to produce or create an outcome. The behavior of collaboration requires the product owner to abandon the role of drill sergeant and focus on being a leader.

The product owner leads by shaping the backlog and collaborating with their fellow team members. The product owner will be more successful if they embrace the principle of the business and developers working together in collaboration, making them more of a leader than a drill sergeant.

If not a drill sergeant then perhaps the product owner is a tour guide. If you have ever visited a major tourist site you have seen tour guides shepherding groups of camera-toting tourists. It is easy to see the tour guide role as that of a leader. A typical tour guide plans the logistics of the tour, herds the tour group ensuring everyone is moving in the same direction and implements the vision of the tour planner to deliver value. The goal of our tour guide is to make sure the team begins and ends together, that no one gets lost and the goal of the tour is accomplished. The role provides administrative and tactical leadership to the tour group. But, the tour guide is not playing the role of the product owner. The whole team acts as its own tour guide in Agile based on the principles of self-management and self-organization. In Agile projects the product owner provides visionary leadership. Tactical leadership and administration, the tour guide role, is generally diffused across the entire team.

The arrangement of roles is facilitated by the application of two Agile Principles3. The first principle directs the business and IT personnel to work together on a daily basis. The second principle in play here is that of self-organizing teams. For example, one mechanism that spreads the role of tour guide across the team is the backlog prioritized by the product owner. The backlog represents the vision in bite-sized chunks that the team can then plan and execute. Another example of tactical leadership that the team drives is the standup meeting, in which the whole team acts as cat herders. So, on an Agile project, who is the tour guide that herds the team toward the product owners vision? The answer is that role is spread across the team and that Agile techniques facilitate making sure that we start and end in the correct place.

As we have noted, Scrum calls for three macro roles on every Agile team. The concept of a stable team is important in Agile (and should be in EVERY framework and method) in order to build collaborative capability and trust. Members of the team must be part of a team on a consistent basis to
value delivered from the team. Product owners are no different when it comes to team membership and cohesion.

Product Owners Are Part of the Team: Embed Them
The twelve principles of the Agile Manifesto provide the basis for interpreting and implementing any Agile technique. One of the hardest principles for many organizations to adopt is: Business people and developers must work together daily throughout the project.

Many implementation approaches have been designed to minimize the organizational inconvenience of this principal, such as using proxies for the business or abandoning the principle altogether. The goal is to involve the business users (also known as the product owner in Scrum) so they can act as voice of the product. Fully embedding business personnel into the project team is often considered the most radical approach. However, is embedding really an absolute, radical solution or just an extreme statement used to generate a conversation? Embedding is a powerful tool, that changes the balance of power inside of an Agile team and brings business personnel inside the boundaries of IT as active participants rather than just sponsors or reviewers. The change required to embed product owners means changes in both IT and in the business department the product owner typically works in. The benefits need to outweigh the costs.

Embedding removes the product owner from their normal job and makes them part of a project team. This has an organizational cost, which includes the cost of replacement even if replacement just means that other colleagues have to pick up the slack. A second and more personal cost occurs on long-term projects. Embedded business personnel need a return path back to the business, or a path into the more technical world, or they risk career failure. Other costs may well include opportunity costs for work or projects that the product owner might have been involved with if they were not on a project team. For example, in an organization DCG reviewed in the recently, a lead sales person participated on a critical product development project as a product owner. During the period he was involved, sales from his territory were “off” by more than 50%. The cost of his participation was lost revenue.

The costs of embedding can be high, but the benefits are generally equally large. The benefits of embedding the product owner are generally a reduction in development time as the team waits for answers, a greater focus on delivering important functions and features earlier, a reduction in rework based on faster feedback and often a better connection to the business. The benefits on embedding can be summarized as reducing the cost of development, faster time-to-market, improved quality and customer satisfaction.

Should every project have embedded business personnel? No, not every project requires embedded business personnel, however, most important projects should. Striking the balance between cost and value is part of the art of implementation. While this technique should be the default in most organization, programs and projects, DCG would not suggest that it be applied without an evaluation of the cost and benefits.

Getting the balance wrong or failing to implement the product owner role has real consequences.

Why Agile Projects Fail: Lack of Product Owners
Failure to correctly address the product owners role creates a myriad of problems for Agile projects, each of which can and often have led to project failure. The product owners role can be difficult to implement. The potential problems4 include: not adequately integrating business representatives into the team, reinforcing the perceived divide between IT and the business, and substituting proxies for business involvement. Each Agile team needs a product owner, or they risk delivering the wrong functionality.

Not integrating business knowledge and decision-making capacity (i.e. the product owner) into the project will lower productivity, velocity and the quality of any project. Just think of the best projects in which you ever participated. Generally, one of the reasons was that a sponsor, lead subject matter expert or super-user, was always around providing input and making decisions. In effect, they were acting as a product owner. Project teams make many decisions, large and small, on a day-to-day basis. The choice that the team has is either 1) to make the decision using the knowledge at hand and risk being wrong, or 2) to wait until they can gather more information. The pressure to deliver now means that most teams will absorb the risk and the rework. Having a product owner close at hand makes development quicker and increases quality.

Not implementing the product owner role reinforces the divide between IT and the business, thus reducing the efficiency of communication. There are many excuses for why organizations implementing Agile don’t involve the business in projects, but the one that DCG sees the most often is that the project team doesn’t ask. Excuses for not asking we have heard include: “the business won’t participate because they are too busy,” or “they are not interested” or “they don't want to have anything to do with us”. Remember that the goal of any project (or at least any project that should be done) is to deliver tangible value based on a need stated by the business. Therefore business personnel have a concrete reason for participation; they should make sure their investment pays off. The first step in the process to involve the business as a product owners is to ask the potential product owners and their managers to participate, making sure they understand the role and why involvement is so important.

The use of proxy product owners is a copout, and in most cases represents a firm signal that Agile should not be used. Proxy product owners are rarely the right answer, because they can’t commit and make decisions for the business slowing the development process to a crawl. One DCG client implemented a hard and fast rule that if a project did not have a product owner, then the project was put on hold until it could be started using a standard project management framework. Without the infusion of business involvement in the day-to-day operation of the project, the organization decided that a classic deliverable-based framework was more appropriate.

The product owner role is critical to linking Agile development teams to the business. Product owners bring business acumen to the development team. That reduces rework and increases the overall acceptance of the product. Choosing not to implement the concept of product owners or to use proxies is rarely the right answer. Bite the bullet and talk to the business users about how they can integrate into the process. Appeal to the fact that it is their money being spent and their involvement would maximize value. If the business can’t commit to participating as product owners, consider not using Agile mechanisms (like Scrum) and instead begin the lean to Agile transition with techniques like Kanban. Kanban is a flow based method that does not require any process changes (at least initially) or role changes.

The Product Owner Is A Role Unto Itself: Don’t Share It!
The role of product owner is critical for ensuring that the rest of the business and the IT team work together effectively. It also requires significant effort on a daily basis. The product owner provides vision, mentors the team, answers questions, makes decisions about the product, communicates with the broader organization, negotiates resource contentions, coordinates business interaction and serves as a liaison to leaders. In short, the role is difficult and complex. So much so that it has been suggested on more than one occasion that it is the most challenging role in Scrum. The product owner should not play any other role on an Agile team5. There are many potential pitfalls in Scrum, however potentially the most destructive and easiest to avoid is the overworked product owner. Overworked product owners are less effective.

What happens when someone is overworked? Sooner or later they will neglect something and cut corners. Some work gets jettisoned as they try to bring their life back to equilibrium. Overworking the product owner may result in non-attentiveness to the team, neglect of grooming the product backlog, and unavailability or missed meetings. It is possible that the product owner will neglect their day job, however, basic psychology suggests that people tend to focus first on that portion of their job that is most important to their long-term career. Unless product owners are focused specifically on a project they will tend to neglect the product owner role (pleasure/pain response6).

The product owner role is challenging; to perform it in a manner that is effective requires effort and focus. Organizations need to ensure that product owners have enough of their time allocated to the product owner role. Work generally needs to be taken off their plate. The rest of the team needs to support the product owner so that obstacles are minimized. Avoid Overworked-Product-Owner Syndrome and make sure the person that is playing the product owner role has the time needed to focus on the project rather than view the project activities as work they can avoid.

Product owners are an integral part of most Agile teams. They bring their business acumen to the team and act as the voice of the customer. Teams without a product owner who is close at hand will either make decisions based on their knowledge of the situation or wait until they can talk to the product owner or other stakeholders. Time is money both in terms of waiting for a decision and delay in getting feedback. Product owners provide vision and leadership to an Agile team. Vision and leadership are not improved by distance or scarcity, so keep your product owner close at hand.

Conclusion
Product owners are an integral part of most Agile teams. They bring their business acumen to the team and act as the voice of the customer. Teams without a product owner who is close at hand will either make decisions based on their knowledge of the situation or wait until they can talk to the product owner or other stakeholders. Time is money both in terms of waiting for a decision and delay in getting feedback. Product owners provide vision and leadership to an Agile team. Vision and leadership are not improved by distance or scarcity, so keep your product owner close at hand.

Sources
1 http://www.scrumguides.org/scrum-guide.html#team, August 20, 2015
2 Mike Cohn, https://www.mountaingoatsoftware.com/agile/scrum/product-owner, August 20, 2015
3 http://agilemanifesto.org/principles.html
4 https://www.scrumalliance.org/community/articles/2010/april/common-product-owner-traps, August 20, 2015
5 https://www.scrumalliance.org/community/articles/2010/april/common-product-owner-traps, August 20, 2015
6 http://www.intropsych.com/ch09_motivation/pleasure_and_pain.html

Written by Default at 05:00
Categories :

The Kanban Game at the Agile Business Conference

Agile Business Conference

 

Join Alan Cameron, DCG-SMS Managing Director, at this year's Agile Business Conference in London. The conference takes place October 6-7th, and it is focused on exploring how an organization can sustain an Agile environment, both in terms of the life of a project, as well as in reference to the culture of the organization as a whole.

This year, Alan will be taking part in the conference by leading the Kanban game. Kanban is a framework used to implement Agile - a better understanding of Kanban can (and should) lead to a more successful Agile implementation. Of course, the best way to learn and retain information is via hands-on activities - and that's where the Kanban game comes in!

Participants will play the game and encounter a series of common business challenges that need to be resolved. In the process, they will learn how to use and apply the principles of Kanban and how the framework is useful in an Agile environment.

If you're at the conference, you can join in on the game on October 7th at 10.10 and 13.35. If you're not at the conference, you can play too! We can come into your organization to lead the game and help your team to better understand Kanban, Agile and Lean. More information is available here.

We always enjoy the Agile Business Conference - it's a great atmosphere, and the presentations, workshops and sessions are always engaging and interesting. We're looking forward to the event - and we hope to see you there!

Written by Default at 05:00
Categories :

Story Points, Function Points or Both?

Scope of this Report

Story points and function points are both methods for ‘sizing’ software. This Trusted Advisor report will establish why sizing is important and present an overview of the two sizing methods, followed by a discussion on the merits of both story points and function points by answering some very common questions:

  • Can I use function points on an Agile project?
  • Story points are much easier and faster than function points, aren't they?
  • Is there a relationship between story points and function points?

Importance of Sizing

When managing the delivery of your software product you need to know how big or small it is so you can properly plan, estimate and manage the delivery of that software. Sizing software requires a size measure that is ideally meaningful to both the development team as well as to the end user. And it should be a measure that can be applied consistently across all projects and all applications.

The development team will want to have an accurate measure of size so they can properly estimate the level of effort and duration. They will also use the size measure to monitor changing requirements (scope creep) as features or functions or stories are added to the original requirements document or product backlog. An end user or Product Owner may want a measure of size so they can understand the relative business value of what is being delivered; what features and functions the user is actually getting.

Story Points

Story points are a relative measure based on the team’s perception of the size of the work. The determination of size is based on level of understanding, how complex and how much work is required compared to other units of work. Story points are expressed according to a numerical range, which is usually constrained to a limited set of numbers such as an adaptation of a Fibonacci sequence (e.g. 1, 2, 3, 5, 8 etc.).

Story points are a relative measure used by Agile teams typically during a sprint session. Each story is assigned a story point value based on everyone’s best understanding as to the “level of difficulty” of that particular story. Of course, “level of difficulty” can include different things such as complexity,
size, duration, effort and so on. Regardless of the scale being used, in a process called planning
poker, the values assigned are assessed independently by each individual, compared by the team
and then discussed to reach a consensus. There is no consistent definition of what the values
represent other than to use it as a comparative value of one story being larger/harder or
smaller/easier than another within the one team. Over a number of iterations (sprints) an Agile team
can develop a consistent velocity (number of story points delivered per sprint) which can serve to
estimate future amounts of work/effort in future sprints. Of course, even if that one team is
achieving exactly the same volume/complexity of work as another team, their story points will not
necessarily be the same.

Function Points

“Function points measures software by quantifying the functionality requested by and provided to
the customer, based primarily on logical design”; as defined by the International Function Point
Users Group. Function points measure “software size” or, more precisely, the size
of the requirements/design specified to which the resulting software provides a “no more, no less”
solution. The size of a defined business requirement is a necessary piece of information if you want
to estimate how long it will take and how much effort it will take to develop that piece of software.
Unlike story points, function points are a defined, reproducible unit of measure. They can be
measure consistently regardless of who is measuring them. Function points can be used on both
Agile and non-Agile projects. For example, Agile user stories, for the most part, describe the features
and functions requested by the product owner.

The function point methodology calls for the identification of 5 key elements including inputs,
outputs, inquiries, interfaces and internal stores of data. Naturally there needs to be some
description of these elements; e.g., requirements documentation or stories, in order for a function
point sizing to be accomplished. Once a function point size is determined it can be used to estimate
level of effort or on the backend, the size information can be used to calculate productivity
(fp/effort hours) and quality (defects/fp) levels of performance.

Some Answers

Can I use Function Points on an Agile project?


Yes, function points can be used on an Agile project. In fact, both story points and function points
can be used on Agile projects and serve to effectively manage the project and measure
performance.

We already know that story points are used to size the user stories for a given sprint/iteration.
Stories can also be sized using function points. However, you don’t need to use function point size to
estimate how long a collection of stories in a sprint are going to take because you have already set
up a 2, 3, or 4 week cadence for your sprints.

Function Points are most useful and frequently used at the beginning of an Agile project and upon
delivery of a release or some significant delivery of functionality. In the beginning of an Agile project, you may use function points to size the entire backlog and use that size information along with additional historical data points to estimate a total project cost and a predicted delivery date. At the backend of the project you may capture total function points delivered to look at performance levels and compare Agile project performance levels to performance levels of other methodologies currently in use.

Story Points are much easier and faster than Function Points, right?

This is a true statement; story points are quicker and easier than function points. The question really becomes, which method is more appropriate for the task at hand. Sitting down with the Agile team and assigning story points to selected stories for a sprint backlog is an excellent exercise in approximating the complexity and required effort of selected stories. This is a collaborative approach that involves the team and provides a group understanding of each work element (story) and what may be involved. Even if story points were not assigned, the discussion alone would be of significant value in driving team efficiency.

Function points require a more detailed examination of the information (stories) available and achieving reproducible counts requires expertise and practice. There are specific guidelines to be applied and calculations to be made. It may be unrealistic to expect every team member of an Agile team to have this skill set. As a result, the use of function points throughout an organization is usually performed by a central specialist team thus allowing for comparisons among the various Agile teams and portfolios.

Function points are also a size measure that serves both the developer and the end user. For the developer, they are used to manage the project outcomes. For the end user (product owner) Function points can be a useful vehicle for setting expectations with regard to identifying (and agreeing) what features and functions are being developed and deployed. However, the direct involvement of the Agile team members in sizing the tasks they are going to work on has motivational benefits over the seemingly imposed sizing of the Central FP counting team.

Easier and faster are nice, but that is not the issue. The issue should be about which metric or set of metrics will provide you with the information you need to best manage the software deliverable, to make decisions and to manage expectations.

Of course, the real issue with the speed and ease of story points is that they are hard to scale across many Agile teams. For the Agile teams themselves this is not an issue but for the organization which needs to build product road maps, annual budgets, resource plans and so on, the loss of coherence is a significant one.

Is there a relationship between story points and function points?

The narrative below references the following example:

Iteration 1 – the team completed 10 stories (in a two week sprint) that were assigned a total of 50 story points. The function point size for those 10 stories was 100. The stories were focused on simple transaction I/O processing.

Iteration 2 – the team completed 5 stories in their second two week sprint. The stories were assigned 55 story points in total. The function point size for those 5 stories was 25.

Question: Assuming the team has achieved a fairly consistent velocity (50) why isn’t there a correlation between SPs and FPs?

Observations:

Story points are often assigned with some consideration of required level of effort. In the first iteration the stories involved fairly simple processing and therefore were assigned an average of 5 story points each. In the second iteration, the stories represented more complex processing and were assigned an average of 10 story points.

Function Point Analysis does not consider level of effort. It is accounting for the features and functions being delivered. The stories in iteration 1 were about processing inputs and outputs and accounted for a high number of function points. In the second iteration the stories required a greater degree of processing logic, but the features and functions being delivered were fewer.

Story Points or Function Points

Story Points are a relative measure whereas function points are a well-defined consistent method of sizing.

Does this mean that function points cannot be used to estimate at a sprint level? Sprints are time boxed, usually as two week iterations. The desired state is to achieve a steady flow of work from sprint to sprint (velocity). For Agile teams, this is adequately measured using story points. Function points are more appropriately applied to measure the overall project outcome. This can be done upon delivery of a release and/or function points can be applied when the product backlog is first developed as a means to estimate the total level of effort that may be required across all sprints.

Conclusion

Story points versus function points; so do we settle on one or the other or both? The answer is, yes.
Both these measures are useful and serve the intended purpose to more effectively manage a software deliverable.

Function points are good for measuring the overall product deliverable at the beginning and at the end. The FP size information at the beginning of a project can be used to estimate overall schedules and costs. Also, the size information upon delivery can be used to measure performance.

Story points are an effective method for managing the flow of work in an Agile project. They too serve a purpose of estimating the amount of work that can be accomplished by the team in a defined period of time (sprint/iteration).

Clearly, sometimes the best use of these two methods overlaps and so it is important to make strategic decisions about when and how they will be used rather than local, tactical decisions.

Written by Default at 05:00

"It's frustrating that there are so many failed software projects when I know from personal experience that it's possible to do so much better - and we can help." 
- Mike Harris, DCG Owner

Subscribe to Our Newsletter
Join over 30,000 other subscribers. Subscribe to our newsletter today!