It’s amazing how the most innocuous statement can get the mind racing. One of my teammates went to a Lean Coffee meetup here in town and when I asked how it was she simply gave me the phrase “dual track Scrum”. It had been a while since I’d heard someone mention dual-track Scrum or dual-track Agile. Hearing it again got me thinking about its implication to Agile software development. (Thank’s Rose).
In case you are not familiar with the concept, read Marty Cagan’s article on the subject. For the record, I’m a big fan of a lot of Marty’s stuff. In a nutshell, dual-track Agile is characterized by a Discovery track and a Delivery track that run concurrently. The Discovery track is focused on generating good backlog items (probably meeting teams definition of ready) while the Delivery track is focused on developing and releasing software. The output of the Discovery track is input for the Delivery track.
Dual-track Agile is implemented by many Agile teams in many different ways. Some teams just have a single role on the team creating validated backlog items; others employ an approach similar to the “3 Amigos” where multiple prepare the next set of backlog items to be worked and some scaled Agile approaches have a completely separate team responsible for creating validated backlog items. My least favorite approach is the approach that has been popularized by some scaled Agile frameworks.
So why do teams practice some form of dual-track Agile? It’s to prevent the delivery track from spinning on backlog items that are to be worked on next. I liken it to a scout or advance team going ahead and preparing a campsite for the rest of the team so that when the rest of the team arrives; it can focus on setting up the camp (instead of clearing brush, fetching water or getting firewood).
Agile Principle #1: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Agile software development is characterized by regular feedback from customers (stakeholders) as feedback guides the team on what to work on next based on what has everyone has learned from what has been delivered. This is why principle number 1 is so important. Often people see it to be important only from the perspective of getting something into the customer’s hands. This is true but incomplete in my humble opinion. An additional reason why we want to deliver valuable software early and continuously is so that we can learn what really needs to be done next.
If our backlog is largely ordered independent of customer feedback then our team is not exploiting all that Agile software development has to offer. Our goal has become to get through our backlog as quickly as is possible – some may consider this to be a project. Value has largely been predetermined upfront. Some may argue that Agile doesn’t make sense for us if we’re working in this manner while there may be some truth to this, I wouldn’t advocate abandoning everything Agile if a team finds itself in this situation. We may just need to make the best out of the situation while realizing that there is a huge aspect of Agile software development that is not present in the way we work.
The output(s) of the [Sprint] Review (or similar practices) are supposed to serve as meaningful input into the [Sprint] Planning process subsequently guiding the team on what it should work on next. For example, the Scrum Guide states the following:
- The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning;
- Review of how the marketplace or potential use of the product might have changed what is the most valuable thing to do next; and,
If your teams [Sprint] Review do not serve this purpose then [Sprint] Planning is largely pre-determined based on other factors that most likely do not include customer feedback on what has been delivered.
If as a team we are pretty sure on what we will work on next before completing what we are currently working on, dual-track approaches might prudent. They will probably reduce (what is correctly classified as) waste in the process and improve our cycle times. However, there is the danger of operating in a “waterfall-like” manner with handoffs especially if another team is responsible for creating validated backlog items.
So here is my question for us. If you are thinking of using dual-track Agile, why do you think it will work? Is frequent customer feedback guiding what the team works on next or do you have a backlog of items with the order of delivery largely predetermined and the team is just making its way through the list as fast as it can (showing progress as it goes)? Is this what it should be? Is this the best it can be? What do you think it should be? How do you intend to change things? Can you?
Remember that “a little learning is a dangerous thing”. Progress is dependent on the unreasonable woman or man.
Recently I was featured on the Scrum Master Toolbox Podcast.
Check it out: http://www.scrum-master-toolbox.com/?s=ebenezer
Over the last 48 hours, I’ve been engaged in some #NoEstimates conversations. A tweet this yesterday evening re- introduced a very interesting dimension to the conversation (at least in my opinion).
What risks are we possibly concerned about here? I can think of two related to the actual process of software development and one related to the people actually doing it, so in all 3 major risks (even though I wouldn’t be surprised if there are others):
- Risk of team not developing the right thing
- Risk of team not delivering on time
- Risk of team not doing their best
Getting It Right/Being On Time (Value 3, Principles 1 and 4 at least)
It is my experience that software development is largely non-deterministic and empirical. YMMV. (If this is not your experience, I’d love to hear about it and the software you develop). There is a significant amount of learning that occurs as the work is being done. Just pull any developer off any team and ask if they “figure things out as they do the work?”. I’ve been developing software long enough to remember a number of approaches to software development that tried to front-load learning via the use of documents and models of other forms. We still found ourselves learning a lot as we actually typed lines of code. We can debate ad nauseam as to whether our discovery process was broken and I imagine there are those who simply say that we should just get better at identifying and writing requirements. There may be some truth to that, but I’m positive it’s not the only way.
Agile as an approach to software development desires to exploit the uncertainty and learning that is inherent in software development. This post is not an Agile primer and yet a meaningful study of Agile methods/frameworks shows that the first two risks are actively being addressed all the time as the team works together to deliver working software. Remember the team includes the paying customer. They are part and parcel of managing the first two risks as we go along. They are part of actually providing a solution. If the customer is not heavily involved in the development of the solution, and yet wants a guarantee around the first two risks, then you may need another approach that lends itself to such an engagement – I’m not sure Agile is it?
So this puts us in the land of contracts. By contracts I am referring to any agreement (verbal or written) on what is going to be delivered and when it is going to be delivered – think funding models as well. When a team commits to delivering X scope in a period of Y, a contract has just been put in place. The nature of the contracts ultimately impacts the behavior of your teams, which impacts how software is truly developed. But we know contracts don’t guarantee results (think about all the prenup’s that have gone by the way side), they guarantee (maybe) a course of action when things go wrong. They can be an indicator of low trust.
This is an opportunity to go read up on what Agile contracts look like (there is no shortage of resources on this topic). But the essence of many of them is that the buyer makes small bets while remaining part of the team. Do they often bear a larger percentage of the risk? Possibly. They often reap a larger share of the reward as well. What they don’t do is handoff a problem and say “see me when you’re done”.
If you thought that software development happens in a bubble, you were mistaken. There are multiple organizational conditions that influence it directly and indirectly. It’s not just something that those technology guys and gals are doing. Agile software development is disruptive to the “normal” way of working. It requires the investor to be part of the team in some form or fashion.
Having a Committed Team (Principle #5)
Ok, so maybe I can leverage Agile contracts for work that is outsourced but what do we do when the team is part of our organization and is salaried? We could be paying them and not getting results. Well, this leads us to risk 3, the risk of the team not doing their best or to put it more bluntly, not being committed. While we can definitely focus on getting the team to comply with internal contracts and similar instruments (such as threats), things are not often what they seem to be. Metrics and efficiency numbers that show a team is “working hard”, “improving” or “getting faster” are not a true indicator of a teams commitment. Maybe they are an indicator of compliance, maybe. (If compliance is good enough for your organization – Agile is probably not a right fit). Leaders who are looking for what they deem to be “tangible” stuff should really be focused on how much value is being created and generated.
Here is a formula for committed teams: Hire great people, create cross-functional teams, give them meaningful work, share with them how their output as a team will make a difference, tell them about important dates and budget and then let them loose. Support them by providing enabling conditions that allow them to excel. Follow’s Drucker’s advice; see them more as volunteers than anything else. This requires you to discard your Theory X approach to management. It requires you to actually trust them – if they are committed they’ll share in the risk as well.
Manifestos and Things
Take a look at the Agile Manifesto (I’m sure you can find it). If you look at it carefully you’ll see that this post has gone over some of the Agile values and principles. This, to me, is what software development guided by the Agile Manifesto is all about. It’s not just about standups, backlogs and story points. In fact, I consider those important but lesser. It’s about a particular culture of developing software. Any method that consistently demotivates or disempowers is not Agile. This is at the center of the #NoEstimates dialogue in my estimation (excuse the pun) – the culture of software development and hence the engagement models that arise as a result of the culture. (Sidebar: I find myself continually saddened by Agile leaders in organizations and consultants who don’t get this and still claim to be leading Agile transformations. They are doing more harm than good). Agile is not mandatory, it’s choice.
In Agile software development, the risk is shared and mitigated by everyone involved (including the investors) by working together in an Agile manner with a committed team. This may or may not work for you – it does not however mean that it is not an option (or the only option).
(I really should be at the piano but I find that there are few things on my mind this morning).
I find myself engaged in my fair share of conversations around accountability in various settings – particularly the Western world’s spin on it. That is, who can we hold accountable when something goes wrong? As I’ve blogged in the past, I personally think that individual accountability for team outcomes is a bit misguided. Debating “who gets called in the middle of the night” is truly missing the point. If you structure your organization in a manner such that individuals are solely accountable for team outcomes then don’t be suprised by the behavior that follows.
(As a leader, you are first and foremost a system designers and influencer. Don’t forget that.).
However, I do wonder what would happen if leaders spent half the time they spend debating who is accountable, actually promoting individual and team ownership in their organizations. Do individuals and teams feel ownership over their work, processes, techniques and outcomes? Or do they feel like their stuck simply following instructions? A means to an end? It’s not enough to simply talk about it, we need to intentionally create the conditions that actually support ownership at all levels.
Does your organization have a culture of ownership? What would a random survey show if you asked that question within your organization? How much time is spent discussing what needs to be done so that individuals and teams actually take more ownership? Nothing is a panacea and yet low ownership levels leaves a lot on the table.
Let’s focus more on a culture of ownership, maybe it’ll address our accountability problem.
(Now off to the piano…)
Is your organization highly centralized or highly decentralized?
Lean organizations are characterized by pushing decision-making to the “lowest” possible level. In the using the word “lowest”, I am just reflecting the hierarchy that exists in most organizations. What we’re really talking about here is ensuring that decision-making occurs where the work is actually happening. In order to enable this, the information also needs to be shared with the team(s) actually doing the work.
This is at odds with traditional work structures where people at the top were paid handsomely to have all the information and the peons were given such dumbed down tasks, that they didn’t have to do much thinking. Take a few minutes to study the history of industrialization. You may be surprised at what you uncover. Unfortunately, this “thinking” still influences the control structures of the average organization.
Even though in knowledge work, the “associate” is often a highly trained and educated individual (see Drucker), most organizations still create structures where all the important information is held at the top. You know, with Director X, VP Y or C-level exec Z. Nothing meaningful gets done without a decision being made by someone with a big title. Supposedly, those at the top are more informed and have more experience. Supposedly. The Taylorist mindset lives on; cloak and dagger style.
You can choose whether you want to work in organization like these. I made up my mind a few years ago that I wouldn’t except I was helping to the change that situation. You know why? I can’t stand to see so much human potential wasted.
Additionally, the delays introduced as a result of waiting for people at the top to make decisions impacts us economically (well except we’re a monopoly). Innovation is stifled, creativity pretty much killed. But someone still ends up with a fat bonus.
As a leader, how much decision making is centralized in you? How much decision-making is decentralized on your team? How much information is given to individuals and teams that enables them to actually make decisions? How many centralized boards and bodies does your organization have?
The greater the centralization the lesser the ability for the organization to scale and the more human potential is being wasted. The waste of human potential is such a sorry thing.
Are we are addicted to the old status quo? Could it be that all change initiatives we participate in are just a facade? Lipstick on a pig? Fun and games? Could it be that the way it is, is the way we really want it to be? I could get into examples but I’ve decided to protect the innocent today.
How can we tell? Well, change often implies that we enroll in some way new of thinking. A different set of values (supposedly) become important to us. We make decisions based on fresh set of principles.
I get that. So pray tell, how can we tell? Ask yourself this: what happens when things get tough? When things become uncomfortable? Do we revert to our old values and principles? Do our entrenched mental models step into high gear? What behaviors emerge? Old or new?
I often find in organizations (faith-based, social, work etc etc) that we talk a good game about how we want to change and how we intend to act differently. Unfortunately, our actions speak so loud that no one can hear what we’re saying (Jeff Van Gundy). Our behaviors are unchanged.
I’ve always believed that true change can only come about by assessing if our actions as invidivuals and groups are congruent with our (new) values and principles and then asking for help when they are out of wack. Change is hard. Good intentions are not enough. A lot of humility is required. The humility lacking in many of us.
Are we addicted to the status quo?
Really? Ok maybe. Then again, maybe not. It’s totally up to you and your organization.
Change is hard as it goes against what we know or what we are currently comfortable doing. It’s always been interesting to me that the Satir J-curve models going from chaos to new status quo as going up a steep slope. It’s very clear that we’re working against gravity and the pull to go back to where we were and what we’re familiar with.
The 4 values and 12 principles of the Agile Manifesto are supposed to help us see the areas where we can get better – at least if we wanted to be guided by Agile philosophy. Getting better often means challenging and changing some tough stuff. Tough stuff that actually makes a difference. Not just implementing 3 week iterations or estimation with that thing called story points. I mean those things are good, but in doing so we often ignore the most important stuff. I often run into folks who consider leaving the (old) status quo as being pragmatic and suggest that those who desire change are “purists” or “idealists”. Ok, possibly guilty as charged.
Here lies my comfort. Progress is dependent on the unreasonable woman and man.