Cycle time, lead time, and continuous improvement

After some time, I have picked up Storify for a few projects that I have been looking to work on. This one will be based around resources to learn more about cycle time, lead time, and other measurements which can be used toward continuous improvement. Since I am being referred to new resources from colleagues on a daily basis, it seemed a great way to keep up with the various pieces in a visual way.[View the story “Cycle time, lead time, and continuous improvement” on Storify]

 

 

 

 

 

 

 

Enter the Scrum: From Development Chaos to Agility and Control

Recently I was interviewed by Mathew Schwartz at Dice.com for I/T workers looking to learn more about Agile development. The article, Enter The Scrum, was published today and I received a couple of nice quotes.

Note: Unfortunately the link to the original article is now dead, so I’ve reprinted it as it originally appeared at http://career-resources.dice.com/articles/content/entry/enter_the_scrum_from_development

Enter the Scrum: From Development Chaos to Agility and Control
By Mathew Schwartz

Software developers, behold the Scrum.

Not a rugby aficionado? The term means the mass of interlocked players – tough lads, fearless lasses – facing off against their opponents when play restarts, each trying to kick the ball back to their side for possession. Think order out of chaos. Some bleeding may result.
Minus the cuts and bruises, the Scrum development methodology is similar. Scrum calls for a single, cross-functional group, ideally with 10 people – including business stakeholders, multitalented tech folks and a ScrumMaster playing project coordinator – all located in close physical proximity. Together they focus not on tools or technologies, per se, but business results.
To do that, Scrum employs sprints – originally four weeks long, now typically two weeks in duration. Each sprint is a plan to deliver fully working, tested and implemented code. For every sprint, the team together decides which capability has top priority, creates a plan, delivers, then reviews what it’s done.

Time to Sprint

Benefits to this “controlled burst” approach include delivering more relevant software, lowering business risk and creating more satisfied coders. “Every two weeks we get the chance to improve what we’re doing, and we can do it with the customer,” says Alan Atlas, a certified ScrumMaster trainer and agile development coach with Rally Software in Boulder, Colo. “No longer do we have to spend two years to see if something we build will work.”

Hierarchy? Stuff it. Scrum teams self-organize. Waterfall approach? Don’t bother. What if the customer requests change? Of course they will, so build in a mechanism for change requests and reassessing priorities.
What if the business request doesn’t work? “We’re very quickly able to tell the business whether it’s viable or not, or whether it’s something they need to rethink,” says Adam Monago, VP of client service for ThoughtWorks Studios in Chicago. In other words, the two-week Scrum sprint was still time well spent.

The Scrum Rush

Scrum isn’t news to many businesses. Indeed, according to a 2009 survey conducted by Tom Grant, senior analyst at Forrester Research in Cambridge, Mass., roughly one in three software development teams used at least some kind of agile development – an umbrella term that includes Scrum, Crystal Clear and Extreme Programming (XP), Crystal Clear, lean and now kanban.
“Though Scrum is clearly, by far, the most commonly adopted,” says Grant, “it’s important to stress that what teams are doing is a mixing and matching exercise.”
Why mix and match? One reason is to augment Scrum with software engineering best practices. For that, Monago at ThoughtWorks Studios says many organizations also embrace XP, which emphasizes test-driven development (“only write the code you need”), continuous integration (build and link code regularly to prevent costly errors) and refactoring (“constantly tweak the code and make it prettier”).

Developers Play Ball

If you build Scrum teams, will developers sign on? “Done well, Scrum seems to speak to a large portion of the high-tech development community,” says Rally’s Atlas. Points in its favor include empowering teams, letting people see their direct impact on a project, keeping people cross-skilled and thus marketable, and reducing paperwork to a minimum.

But Scrum does have pitfalls. “Lots of organizations leave a lot of money on the table by not going all the way,” says Atlas. “There’s a great deal of difficulty and discipline involved to get past 50 years of organizational memory about how we’re supposed to do projects.” Indeed, everything from management and support to HR systems and compensation require rethinking.

Get Scrum Savvy

When it comes to mastering Scrum, either as individuals or organizations, experts recommend studying the fundamentals, but also bringing a coach onsite for the first few months to help put Scrum theory into practice, starting with one team. Pick an important – but not the most important – project. Do it well, start to turn heads, then expand the Scrum rollout.

Remember that Scrum isn’t dogma, but a lightweight, flexible mindset and framework focused not on tools and technologies, but business results and short project phases planned and executed in two-week bursts. In other words, practice Scrum well, and what looked at first like chaos turns out to imbue software development speed, flexibility and control.

Jim Grenning on Iteration Zero

I recently had the pleasure of reviewing Jim Grenning’s paper Iteration Zero which was published and presented at this year’s Embedded Systems Conference in Boston.  It’s very good and you can download the paper and slides here:

http://www.renaissancesoftware.net/papers/80-agile-requirements-estimation-and-planning-iteration-zero-embedded-systems-conference-2010-boston.html

If you don’t know if Jim, he’s one of the original Agilists and creator of the technique known as Planning Poker.  He spends much of his time trying to bring Agile to those in the embedded C space.  He’ll be presenting at Agile China in October 2010 as well.

Best practices for adaptive software teams

Software teams, in the broader sense, are complex adaptive systems. They live

within organizations populated by many actors, influenced by the methods,

practices and behaviors that coexist with them. Most of all, they have the capability

to learn and adapt to each new entrant into their world. It is for this reason that, we

tend to avoid recommending ‘best practices’ that all software teams can follow for

success, let alone ‘agility’.

adaptive-software-team
Software Delivery Team at ThoughtWorks

There are practices that when employed together can promote beneficial behaviors

or expose harmful ones in the surrounding environment. For example, the use of

continuous integration can on a basic level expose unintended defects in the

boundary points of two pieces of software. At a more significant level, this practice

can be used to influence the behavior of software developers to increase perceived

ownership of the solution and to reduce tolerance for less-disciplined colleagues

working within the code base.

Continuous integration is but one part of a more effective system of activities,

practices and behaviors that many describe as continuous deployment. In this

system, software is designed, developed, tested and deployed rapidly and regularly,

often daily, if not multiple times a day. What makes this so complex is that it

involves a change in mindset across many roles on the team. In order to deploy

continuously, teams must conceive of the smallest possible features and implement

them without gold-plating. Breaking this approach down further, it deals with

keeping batches of work small enough that defects are easier to find and fix, and

process issues can also be sorted out quickly. The philosophies powering this

approach are drawn from lean manufacturing; the overarching pursuit being the

elimination of Muda, or waste – wasted features, wasted software, and wasted

money.

At the core of both of these approaches is testing. Arguably, testing is the single

most important activity for development teams to undertake. There are successful

teams that employ very sophisticated arrays of automated tests, and some that are

successful doing it manually. The degree of automation necessary is typically

correlated to the scale of the system being developed. What is more important is

how closely the testing activities reflect the expectations of the customers and end-

users of the software. It is from this, that so many other ‘best practices’ are derived.

At ThoughtWorks, we have defined our ideal state as being one of

continuous delivery: one in which the customers and users of software have

maximum ownership and influence of the development process. This system

involves discipline by all actors in the system, from the leadership that provides the

trust and guidance to software teams, to the teams that regularly fulfill the changing

needs of their customers. There is no recipe for teams to follow to meet this goal,

but there is the willingness to observe, adapt and respond to the change that meets

them.

This article was originally published in Tech Journal South, but has been republished here as that publication has gone offline.

Adam at Agile China 2009


152, originally uploaded by AgileChina2009.

This weekend I flew to Beijing to give my ‘Agile Analysis Not Fragile Analysis’ talk at Agile China 2009. I was pretty knackered from Jetlag, but the talk went great. The most amazing thing was to see how the conference and community grew since I spoke at the last one there on my birthday back in 2007. Time certainly flies.More pics of Agile China 2009 can be found here and here.

Agile Brazil is coming!

I am very happy to announce that I will be speaking at this year’s Agile Brazil conference in Rio de Janeiro on June 27th. The title of my talk is “Agile Analysis, Not Fragile Analysis”. You can find the complete agenda for the conference here.


I am very excited to speak alongside my colleague Jason Yip, and to meet lots of new Brazilian agilists. Who knows….maybe we will manage to arrange the first local Mingle User Group in Rio de Janeiro. 🙂

I’m very proud of my friend and colleague Paulo Caroli for all of his hard work in helping to organize the conference, but that’s no surprise from a guy who puts quality into everything he does. Well done Paulo!