• Prev
  • Next

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 :

Agile Transformation of the Organization – A New Year’s Resolution

Lightbulb MomentMany of us have experienced the refreshing and self-reinforcing flow of benefits from introducing Agile to our software development organization through scrum. As I write this, I am smiling at the memory of light bulbs going off in some of our clients’ heads as they realized how scrum can cut through the ambiguity surrounding many traditional projects to provide a clear, frequently renewed, focus on value delivery and customer satisfaction. 

 Of course, in many instances that fresh feeling has turned into a little bit of a headache as we struggle with the challenges of scaling Agile. This really shouldn’t be too much of a struggle because we now have approaches such as the Scaled Agile Framework® (SAFeTM) and DSDM.  But, the headache comes from the biggest challenge associated with implementing enterprise Agile for software development – the need to change the organization outside of software development. 

Something as fundamental to scrum as daily builds requires a significant rethink in some organizations. I can remember, on one of my early scrum implementations, being told that the IT teams required three weeks’ notice to set up the hardware for a new test environment.  Important though it is, this tactical level change is not what I am referring to in this article.

The key to successfully implementing enterprise Agile is to implement strategic change. Using SAFe as an example, at the team level, the scrum teams work broadly, as they always have, with minimal impact on the rest of the organization. A benefit and constraint with scrum is that it is possible to (and many organizations do) implement it almost in a “black box” that neither impacts nor influences the rest of the organization. But as soon as you recognize the need for and introduce the program and portfolio levels of SAFe, Agile, scrum and, even software development now require changes to the way the overarching organization arranges, prioritizes and funds its work. 

For example, the PMO and the finance department both need to transform their processes to enable the establishment, operation and eventual shut down of Agile Release Trains. HR needs to transform its approach to training, mentoring and career progression to meet the needs of staff placed in new roles and cycling through different roles. 

SAFe -Big -Pic -2.5-1200-x -869

How Scrum Teams Can Help Facilitate Organizational Change

So, how can the scrum teams in software development help their organizations to make these changes? By sharing and fostering the use of scrum techniques throughout the organization. Who better to coach the teams being transformed in the rest of the organization than the software scrum teams themselves? 

Do all elements of scrum need to be applied to all transformations outside software development? No. Product Backlogs (or maybe Transformation Backlogs?), Sprints, Product Owners (or maybe Transformation Owners?), Scrum Teams, Sprint Reviews and Sprint Planning Meetings are all pretty much essential. Daily Standups can be overkill on more strategic initiatives, but certainly some sort of progress and impediment reporting is appropriate on a regular schedule during the Sprint (weekly on a 4-week Sprint works well). Scrum Masters may also be a less important role and should perhaps be combined with the Product Owner, depending on the team.

For us here at DCG, this is no theoretical proposal. We use scrum techniques ourselves for implementing strategic initiatives. And, we use scrum in our consulting contracts to help our clients manage their own transformations. For example, for a client needing to introduce improved IT governance and measurement, we used an Agile approach to help the senior management team identify and prioritize a Program Backlog. We were happy when they concluded that the value delivered in the first six transformation Sprints was sufficient and that no further Sprints were needed.

If you’re curious about how to apply scrum as a framework for organizational change, start with our article, “How To: Enable Enterprise Agile Throughout the Organization.”

Written by Michael D. Harris at 05:00
Categories :

Plus ça change, plus c’est la mȇme chose

DCG 1994 Logo 2C

This is the fifth and final post in a series that offers our management team's reflections on DCG's 20th anniversary and the state of the software industry. Previous posts herehere,here, and here.

I make no excuse for using a French expression, as it sums up things very succinctly. “The more things change, the more they stay the same” is something of a cliché, and of course it’s not completely true, but then again, it’s not completely false.

This year is DCG/DCG-SMS’ 20th anniversary. In thinking about how the industry has changed in the past 20 years, there’s no better way to describe it than the above expression.

The Need For Change

Who remembers SSADM –Structured Systems Analysis and Design Method? Developed by CCTA, who also developed ITIL, SSADM was (and is) a very structured 7-step waterfall process from Stage 0 – Feasibility to Stage 6 – Physical Design; oh, and then you had to build the application. SSADM is the culmination of the Big Process approach to application development; if all went to according to the huge WBS and GANTT chart plan, then you had a perfect system out of the sausage machine.  

It didn’t work, of course. The problem with any process-heavy approach is that the base assumption is that the world stands still while you build the application. We all know that, even with small application builds, a lot of things change our view of the business needs while we’re working.  SSADM was aimed at those government projects that would end up in the top one percent of the size range (5,000+ Function Points – FP), where change during the project is so huge that you can never get to the end point and “analysis paralysis” sets in.

Clearly there was a problem. One project I was on as a requirements manager delivered its first release at 0.5 FP/100 hrs, against industry expectations of about 6 FP/100 hrs. By the end, we were still only producing 1.5 FP/100 hrs and the application was nearly 8,000 FP. You do the math (at £400 per day base cost). The project team was huge and we were all working our socks off. We did deliver, of course, but with a lot of help from EDS, who became outsourcing partners during the project.

So now we have Agile. Large programmes are delivered through smaller applications, built incrementally by small teams, using continuous integration to deliver change quickly and much more effectively. There is process, of course, exemplified by SAFe and DSDM. to provide programme level support for scrum and the development methods at its heart.

In those organisations that become Agile throughout, a software development methodology has become a method for delivering business change. Hooray, the cavalry has come over the horizon and saved the day. Or has it?

Things Stay the Same

So now we’ve moved on. We do things so much better, but still projects fail. The 2014 PMI Pulse report shows that projects include IT waste totaling $109m of every $1bn spent. Highly Agile organisations are better at delivery, and crucially, such organisations tend to be more mature at change management, project management, and have active PMOs. They also have more visible and active project sponsors.

Sadly, in those organisations where effective agility has not been adopted, chaos reigns. Too often we hear the comment, “You don’t understand; we’re Agile, so we don’t need all that process.” Haven’t they heard of minimum marketable features? Where sponsors and teams have no idea of where their business is going, Agile becomes a mask for failure of strategy, and dreams and money get poured down the drain.

So what remains the same is that discipline, foresight, and adherence to Agile processes are key to successful delivery.  People and organisations who were poor at applying waterfall principles tend to be poor at Agile too.

Agile is a disruptive game changer; it can and does increase the rate of delivery while reducing costs, but treating it as a carte blanche for anarchy does the concepts behind it, and the businesses hoping to reap the benefits, no favours.

Alan Cameron
DCG-SMS, Managing Director

Written by Alan Cameron 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!