Are We Ready for Agile – And Are We Following the Money?

Steve KitchingAt a recent conference, one of the overriding themes was that although organisations believe that implementing Agile is a good idea, they are concerned about how they would do it and if they are really ready.

In truth, to implement Agile successfully, the whole organisation has to adjust with the approach and be prepared for the changes it requires.

For example, senior management needs to understand that the objective of Agile isn’t to deliver every software change, but to deliver the most important changes – those with the greatest business value. This requires collaboration between IT and the business. Ultimately, IT must work with the business to follow the money!

You often hear that only the development team is going Agile, but this is inaccurate. There is also a shift in the role of the business owner. Their empowerment to control the backlog is a huge benefit to the organisation. Mishandled, this is the one factor that makes an Agile implementation a failure. Without the business owner, the development team doesn’t have the authority to determine the relative importance of the deliverables or effectively groom the backlog.

Organisations also have to manage their own expectations; during the initial trial, the effort may be very similar to Waterfall as teams adjust to the new processes. Agile is a Lean process; it helps minimise the effect of change, but it isn’t a panacea – you still need the final business vision to drive the development. If it isn’t worth doing for the expected return, then why do it!

Finally, remember that there is still a need for a business process to support Agile. DSDM is a very good framework, which enables the business to reap the benefits of Agile. You may also need to consider how to extend Agile to all of your teams; for that, we suggest the Scaled Agile Framework (SAFe) to control multiple teams working across an implementation.

If the organisation is ready, Agile can be a huge success; if not, unfortunately the finger of blame will be pointed at the process, not the fact the organisation wasn’t prepared to reap the benefits.

As always, we’re here to help. We offer an Agile Readiness Review and a SAFe Readiness Review to help you determine if you’re ready to go Agile.

If you’re looking for help with SAFe, we suggest checking out our Leading SAFe training class, which we’re offering in Edinburgh this October.


Steve Kitching
Software Sizing and Estimation Specialist

Written by Steve Kitching 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 :

The Software Quality and Test Management Conference

We're headed back to the Software Quality and Test Management (SQTM) Conference! This year we'll be taking up residence in San Diego from September 13-18, and, as always, we're looking forward it.

SQTM is the only conference that focuses on how best practices in test management and software quality can increase productivity and and user satisfaction, and we'll be there sharing our own strategies and tactics for how to achieve this.

Tom Cagley, Vice President of Consulting, will give two presentations.

“The Impact of Cognitive Biases on Test and Project Teams” will discuss how our biases affect how we interact with others, thereby affecting the work we produce. Tom will discuss how teams can deal with this issue and how an understanding of these biases can make an Agile team more efficient and effective.

He will also present "Identifying Software Quality Best Practices." This presentation will explain how a team can pinpoint its own best practices in development and then how to leverage those for success.

Both presentations will be available for download following the conference, so be sure to check back here for the links!

We're looking forward to a great conference, and we can't wait to share our takeaways with you.



 

Written by Default at 05:00

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

Leading SAFe® in Edinburgh

Scaled Agile Silver PartnerScaling Agile isn't easy - it takes knowledgeable, experienced people to lead the charge. Leading SAFe is a two-day course that provides you with the information you need to successfully apply the Scaled Agile Framework within your organization or team, reaping the benefits of Agile across your organization.

The good news? We're offering a Leading SAFe class in Edinburgh! If scaling Agile is something your organization is considering, this class is imperative - so don't miss out! Registration is limited.

The class will be delivered by Mike Harris, CEO and SAFe Program Consultant.

The Details:

Dates: 8-9 October
Venue: Edinburgh Training & Conference Venue
16 St. Mary's Street
Edinburgh, Scotland
EH1 1SU

Further information about the class. including payment details, is located here. For more information, or if you have any questions, contact DCG-SMS' Steve Kitching: +44.843.2895174.

Written by Default at 05:00
Categories :

"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!