This post is a placeholder for some notes I jotted down about a recent .NET Rocks! podcast (episode 1260) where the hosts, Richard Campbell and Carl Franklin spoke with guest Chris McDermott.
Context
It’s been three months since I’ve started a new job in a larger company (Department of Defense contracting) that uses Scrum fairly heavily. Having come from a healthcare (i.e., also highly structured) company where I introduced Kanban to the dev department, I’ve found myself paying more attention to Agile process — what works, what we typically misunderstand, etc.
This podcast episode had so many points that resonated with me, I had to go back and write things down so that I could revisit them when I get frustrated, confused, or am looking for talking points on the pros/cons of certain systemic processes.
Notes
Failure is an important thing: It gives us the opportunity to learn.
The world we operate in is inherently complex (i.e., there’s not much linear causality), so we need to experiment.
Make your organizational changes “safe to fail”; try a number of these changes in parallel, and when you find ones that work, latch onto those.
Having the infrastructure to quickly build/test things is helpful, as sometimes it’s faster to go off and build two versions of a feature rather than debate at the whiteboard about what the feature should be.
A large part of what we do is social, so we need to learn to understand each other. Sometimes team-building “games” can be slightly false; just go work together. Some of us like to pair, others don’t; some of us like to test, others don’t. Trying to force those collaborations/techniques can lead to losing momentum.
It takes a long time to build up the relationship/understanding and what the team’s strengths are.
Eat together. Richard Campbell says, “When I talk to project leads, and if you don’t have every lunch planned out, you’re wasting an awesome opportunity.” This is echoed in Coaching Agile Teams by Lyssa Adkins – invite people over for dinner (much more intimate than lunch).
Scientific management involves breaking work down into small pieces and measuring each of them.
Processes are a way of getting people to work together.
Three amigos technique: Before working a story, have conversations across the traditional silos (e.g., business analyst, dev, tester). They each get investment at the start, and everyone gets input about how to get the best result. See: https://www.scrumalliance.org/community/articles/2013/2013-april/introducing-the-three-amigos
Help the work flow instead of having boundaries between functional silos where work tends to go to die (because work queues up).
It’s demoralizing for most devs when they find out code that they wrote isn’t being used, or it’s going to be replaced by someone else’s code (or another vendor’s code).
Devs want to do things that have an impact; if we’re just going to write code for no reason, it’s not very motivational. See Dan Pink’s theory of intrinsic motivation, which involves autonomy, mastery, and purpose — http://www.ted.com/talks/dan_pink_on_motivation?language=en
You need good finish lines – how do you know when you’ve delivered something great? What is your metric?
How do we make sure that the “mortals” understand what we’re doing and why it’s taking so long?
David Anderson, who brought a lot of Toyota thinking to software development, reckons that software is somewhere between 2 and 25% flow-efficient (i.e., the touch time you spend working on a piece of software, from the minute you start to the minute it’s ready to deploy). When someone asks you how long, you have one number in mind, but it’s the flow that’s important. The more time work is blocked (waiting in a queue), the less efficient it is.
The problem in estimation is that the work is complex, and the requirements are emergent (discovered as we go).
Kent Beck’s Extreme Programming Explained says to take all of the things we think are good about software development and dial them up to 11. Extreme programming (XP) talks about iteration (try/change/repeat); Scrum changes that slightly and uses sprints to “do more stuff” and doesn’t necessarily embrace the iterative part because of the longer cadence.
“Agile change” is about taking an iterative approach to finding whatever it is that’s better for your company. Start with where you are now. Complexity says we can’t define an end-state; Kanban aims to focus on finding the problems in how we work so we can slowly improve.
When you’re doing knowledge work, all the work is in your head or in computers. It’s not a factory where we can see the widgets, so we need physical manifestations of it to manage it better (e.g., cards on the wall).
Team of Teams by Fussell et al. – talks about Taylorism (1910s) and how it affects the way in which we build organizations. Managers know more than workers; this model works well with manufacturing. We need to go from top-down thinking to a flow-based customer perspective. This will be a mind shift, because resources need not be at 100% capacity all the time, which traditional management is uncomfortable with.
Get situational awareness – how does your process work now?
The essence of Kanban is change. Scrum is a product development method, and Kanban is a change management method. The hardest thing is to limit work in process.
The Scrum daily standup is an anti-thrashing strategy where you can say where you’re struggling and hopefully get some help.
The Kanban board is used to see the entire system so you can see if you’re blocking things. It helps you visualize the flow and find problems proactively (e.g., too much dev, not enough testing).
A nice link I found to compare/contrast Kanban and Scrum: https://www.crisp.se/file-uploads/Kanban-vs-Scrum.pdf
Tech support is an interesting area to study because you can consider the amount of time supporting an application (e.g., bugs, explaining unclear processes) can be considered waste. That is, had the product quality been higher, there would be less need for support.
Systems thinking is looking at processes and understanding the connections. How are parts of the system working together and how do they depend on one another to get work done? Another aspect is the holistic view – looking at the entire view rather than a subset (i.e., only the systems you’re responsible for).
Richard Campbell says it important to know when to throw the party. A party at dev-complete means only the devs are happy; a party at QC-complete means ops isn’t happy. One solution is to put in enough instrumentation to know when X% of your customers are using your feature.
Is Eric Ries’ book The Lean Startup still applicable? Chris McDermott says it has bounded applicability; it works best in highly unpredictable environments where there aren’t many constraints. For example, it probably wouldn’t work well for a healthcare company (lots of restrictions). Richard Campbell suggests looking at the concept in the book where you build a lean “tiger” team inside your organization, even if the entire company can’t be a lean startup.
Instead of going after the elephant in the room, get some small wins with a new process on more manageable, smaller issues. This builds momentum and makes failure feel less demoralizing.