Disciplined Agile

On June 4th, 2017 I rode in the Heart & Stroke Ride for Heart event in Toronto.  Together we helped to raise $1,380 (not including any matching funds that occurred during two points during fund raising).  I would like to thank everyone who donated,  they’re acknowledged at the end of this blog, to this great cause.

This was my first year doing the ride and ignoring the horrible weather it was a lot of fun.  The temperature when I started out was 12C and it was pouring rain.  Ugh.  And as you’ll see in one of the pictures below I didn’t have proper rain gear for the ride as I normally don’t ride my bike in the rain (I’m a wimp).  Luckily I signed up for the 25K option, 50K and 75K were the other options.  Last week I had been regretting not signing up for 50K but then given the weather I’m glad I went for the short route.  Next year I’ll do 50K as that goes further up the Don Valley Parkway (DVP) which would be a great ride.

Some Pictures From the Ride

The race started at the Canadian National Exposition (CNE) grounds and we went East along the Gardiner Expressway (the Gardiner and the DVP, the two major highways into downtown Toronto, were closed for the day to allow the ride to occur).  In this picture you can see the Rogers Center (formerly the Skydome) on the left in the downtown core.  This was probably about 2KM into the ride at the time.  If you’re not familiar with Toronto, the Gardiner is a raised highway.

This picture was taken around the 20 KM point in the ride.  I’m looking North up the Don Valley Parkway.  As you can see everyone was enjoying the weather, yeah, that’s it.

Here I am, back on the Gardiner heading west back to the CNE grounds.  As you can see I was pretty much soaked through and not wearing gloves.  The night before I was going to go out and get some rain gear, but then talked myself out of it thinking that my “water resistant” jacket would suffice.  Great jacket but it was overwhelmed by the amount of rain.  Live and learn.  And I was wearing shorts, which was a good strategy as they got soaked and long pants would have been worse.

Acknowledgements

I sincerely thank the following people for their generous donations: Karen Lewis, Andres Alarcon, Antonio Valle Salas, Mike Edwards, Robert Wen, James Densmore, David Wight, Kiron Bondale, Adriano Tavares, Timothy Morris, Glen Little, Jane McGrath, Loreen Ambler, Ron Favali, Olivier Gourment, Sheri Crawford, Terry Hamilton, Kristen Morton, Kevin Brennan, Mike Beedle, Chris Kolde, Renato Putini, Gregg Little, Ellen Grove, Carol McConnell, and Jennifer Yang.

As promised, we’ll be sending out signed copies of our forthcoming book “The Executive’s Guide to Disciplined Agile” to everyone who donated.  This should happen towards the end of July.

Looking forward to next year’s ride!

In Time Tracking and Agile Software Development we overviewed why teams should consider tracking their time.  Primary reasons include:

• You’re billing your customer by the hour
• Your organization wants to account for CapEx/OpEx
• Your organization wants to take advantage of tax credits (typically for R&D work)

A secondary reason to track time is because the team wants to measure where they are spending time so as to target potential areas to improve.  This is more of a side benefit than anything else – if this was your only reason to track time you’d be better off simply discussing these sorts of issues in your retrospectives.  But if you were already tracking time then running a quick report to provide the team with intel likely makes sense for you.

So what are your options for recording time?  Potential strategies, which are compared in the following table, include:

1. Automated report from an agile management tool. The basic idea is to extract data from an agile management tool (JIRA, TFS, LeanKit, …) and load it into your time tracking system.
2. Manual input by team members. Each team member, typically once a week, inputs their time into the time tracking tool.
3. Manual input by the Team Lead. The Team Lead (ScrumMaster) inputs the time for their team into the time tracking tool.
4. Manual input by a Project Manager/Coordinator. A PM or Project Coordinator, often in a support role to the team, inputs the time of team.
5. Don’t track time at all. ‘Nuff said.

Table: Comparing options for tracking time.

This blog posting was motivated by a conversation that I had with Stacey Vetzal on Twitter.

Related Reading

• Time Tracking and Agile Software Development
• Agile Software Development and CapEx/OpEx

Key tenets of agile and lean are to work collaboratively and to streamline your workflow respectively. This includes all aspects of your workflow, not just the fun software development stuff that we all like to focus on.  This blog posting explores how Data Management activities fit into your overall process.

In the process flow diagram below we see that Data Management is a collaborative effort that has interdependencies with other DA process blades and the solution delivery teams that Data Management is meant to support. Due to the shortened feedback cycles and collaborative nature of the work this can be very different than the current traditional strategies. For example, with a DA approach, the Data Management team works collaboratively with the delivery teams, Operations, and Release Management to evolve data sources. The delivery teams do the majority of the work to develop and evolve the data sources, with support and guidance coming from Data Management. The delivery teams follows guidance from Release Management to add the database changes into their automated deployment scripts, getting help from Operations if needed to resolve any operational challenges. Evolution of data sources is a key aspect of Disciplined DevOps.

This highly collaborative strategy is very different than the typical traditional strategy that requires delivery teams to first document potential database updates, have the updates reviewed by Data Management, then do the work to implement the updates, then have this work reviewed and accepted, then work through your organizations Release Management process to deploy into production.

In the next blog posting in this series we will explore the internal workflow of a Disciplined Agile approach to Data Management.  Stay tuned!

For those of you who are Star Trek fans you’ve likely been seeing ads for this t-shirt on your social media feeds.  It is an apt metaphor for the empirical approach that we take with Disciplined Agile – we regularly run studies to explore what is actually going on out there on agile teams, we gather data, as opposed to pouting some of the wishful thinking (spreading lore) that we often hear from consultants and vendors.

We are currently running an agile mini-survey of only 6 questions, so this will take you a few minutes at most to fill out, exploring some important issues about agile adoption within your organizations.  We hope that you choose to invest a few minutes of your valuable time to fill it out, and thank you in advance for doing so.

What Will We Do With the Results?

As you already know the surveys that we run are completely open – We share the source data (without identifying information), the questions as they were originally asked, and a Powerpoint deck summarizing our interesting findings after the survey has closed.  In fact, we have the results from dozens of previous studies posted at the IT Surveys page for you to take a look at.

We also write blogs discussing the results.  For example, for the 2016 Agile Scaling survey that we ran in November, we published several blogs:

• Can you outsource and still be agile?
• Do agile teams take on hard problems?
• Do agile teams face regulatory compliance?
• How “whole” are agile teams in practice?
• How geographically distributed are agile teams in practice?
• How large are agile teams in practice?
• Do agile teams pay down technical debt in practice?

Recently, we’ve created a new infographic summarizing the results of the study.  If you click on the thumbnail below it will take you to the page where you can download a high-resolution PDF of it.  This infographic is only available to members of the Disciplined Agile Consortium (DAC).

Where Can You Get the T-Shirt?

If you’re interested in the T-Shirt, it is a time limited offering on Teespring.

The Lean Enterprise genie has been out of the bottle for some time now, but for most organizations he’s still a long way from granting three wishes

The Lean Enterprise … Enterprise Agility … DevOps 2.0 …  BizDevOps … the list of monikers and descriptors for this concept is becoming a lengthy one, but there’s no denying that lean and agile concepts and practices are now mainstream, and pushing to break out of their former boundaries within software development.

Reflecting on this, I came across a very apt description (in, of all things, a conflict simulation design blog) of what seems to be happening in this realm of late:

“Most new ideas, however fresh or spontaneous they may appear at first glance, usually represent an evolutionary synthesis of previous ideas; in other words, when it comes to most things, history really is “preamble”.¹

The idea of bringing business, development and operations people to the same table to act as a tripartite coalition from the very start of product development has been gaining exponential momentum of late. As far as ideas go, it is not an entirely new one of course. Encouraging collaboration from the get-go has long been a hallmark of Agile approaches – in development for example, George Dinwiddie is believed to have coined the term “the three amigos” around 2009² to describe the interplay of developers, testers and business analysts / product owners from an Acceptance Test Driven Development (ATDD) perspective. However, other than describing a tripartite arrangement, the 3 amigos analogy differs from the most recent crop of expressions in that contrarily to say, BizDevOps, it only actually plays on two of the required three planes.

Another oddity that struck me is that one of the first high visibility discussions that I can remember describing the interplay of business, technology and operations actually framed the debate in terms of an antipattern: to wit, a July 2011 Forrester whitepaper which coined the expression “Water-Scrum-Fall”³ as a way of describing the very lack of cross-enterprise collaboration which bedevilled most organizations’ agile efforts.

The need for systems thinking

Unsurprisingly, a silo mentality is the biggest single impediment to achieving true Enterprise agility. Everyone involved in the creation and delivery of business solutions needs to collaborate across the breadth and depth of the organizational structure. Team-level agility in the delivery space alone will not deliver on the promise of the Lean enterprise; nor is DevOps enough. Business, IT and operations all need to break out of their silos and embrace systems thinking.

In both my practice and my teaching, I constantly strive to come up with metaphors that can convey the underlying meaning of concepts in ways that overcome resistance by reframing the issue at hand in a very different manner than what people may be used to. I would now like to share a metaphor that I have recently been using which has shown a lot of promise in terms of getting everyone thinking in terms of the whole system when it comes to the concept of the lean enterprise.

As discussed above, the system in question can be simplified as having three planes:

This however is merely … a triangle, and does nothing to convey the importance of intense collaboration. We need something more evocative.

Something with three parts, yet an indivisible whole. There is actually quite simple that we can use to convey this:

That’s right. True Enterprise agility is neither a sprint, nor a marathon … it’s a Triathlon.

What makes this metaphor work is simply this:

Although a triathlon is made up of three events, it is performed by a single athlete who must excel at all three to win. In this case, the “athlete” is not an individual nor a team, but the whole enterprise.

So, if our organization is reaching a point where it is proficient in delivery, there isn’t much more to be gained by continuing to concentrate all of our improvement efforts in IT alone – the Business side of things must be brought into the game as a full partner. The same goes for operations – even careful, collaborative prioritization backed up by competent delivery will not win the day if ready solutions must then linger for months in pre-production environments. Nothing ground-breaking here, just a fresh way of looking at the issue … no serious triathlete would sign up for the Ironman in Hawaii knowing that she faced daunting challenges in terms of her swimming, or was a less than competitive cyclist. The same must go for our “lean” enterprises. Until we can let go of the silo mentality and learn to act as a single “athlete”, we will continue to be bound by the shallows⁴ of Water-Scrum-Fail.

Endnotes

1. http://mapandcounters.blogspot.ca/2012/04/roads-from-smolensk-spi-dunnigan-and.html
2. http://www.velocitypartners.net/blog/2014/02/11/the-3-amigos-in-agile-teams/
3. Available at https://www.forrester.com/report/WaterScrumFall+Is+The+Reality+Of+Agile+For+Most+Organizations+Today/-/E-RES60109
4. Shakespeare of course. Julius Caesar, Act 4, Scene 3.