Introduction

My current assignment has me coaching a software development group that is responsible for adding features to a legacy product that is on a yearly ‘shrink wrap’ release cycle.  The product is over 25 years old and is approximately 18M lines of code and has millions of users.  There are not many software products out there that are this old and this big and are being developed by a team that wants to embrace Agile.  We are like pioneers in a new territory.

The product development group (approximately 20 teams) started their Agile adoption process approximately 18 months ago on their own.  After a year of adopting Scrum they decided to get an outside perspective on their progress so they contacted BigVisible to help them assess where they were and help plan next steps for Phase 2 of their Agile adoption.
 

Goals, Strategies and Tactics

Two of the stated goals for their Agile adoption were to increase throughput while also increasing quality.  In order to achieve these goals one of our strategies has been to focus on catching defects much sooner in the development cycle.  This meant two things.  First, we will no longer rely primarily on a ‘testing phase’ at the end of the development phase for catching defects but rather engage QA team members as part of each Scrum team so they can test User Stories as soon as they are ‘Dev Complete’.  The teams are embracing this concept of ‘building quality in’ and getting away from focusing on rushing features into the product in order to hit their annual ‘code complete’ date.  (We have also suggested that the developers not start a new story until QA signs off on the completed story in order to keep the developers available for immediate defect correction and to limit work in progress.)

The second tactic we have worked on for increasing throughput while also increasing quality is to introduce more testing into the process.  The group has a very seasoned and effective QA group that does a lot of manual testing and there is a good level of automated testing in place but we felt like we could still raise the bar.  (Most of the automated tests are Silk scripts that test the application from the UI layer. There is some functional testing being done using homegrown test harnesses. But Unit Tests are new for most of the teams so there is very limited code coverage.)

So where do we invest in our testing efforts in order to effectively increase the product’s quality and to increase the team’s throughput?  Because we are an Agile development group and we don’t have much in the way of Unit Testing the obvious answer is to invest heavily into our Unit Testing framework right away.  Right?  Well, maybe not.  Let’s look a little deeper.

Assessment Summary

The following table is an assessment of the five primary testing practices within this development group.  The table shows to what extent each is being used to achieve the goals of the organization.

With this assessment in hand, let’s look at our situation again, this time using the Five Focusing Steps from the Theory of Constraints:

Step 1: Identify where the constraint is in their current process. Our assessment determined that for this client the constraint is QA cycles at the end of the development phase;

Step 2: Exploit the constraint. Can we exploit QA?  In other words, can we squeeze any more cycles out of QA?  Not really, QA is already overburdened.  Let’s move on to Step 3;

Step 3: Subordinate everything else in the process to the constraint. This is interesting.  The rate of which features are being introduced into the system by Devs is greater than what the Constraint (QA cycles) can handle.  This means that Devs should slow down and not work at 100% utilization.  Okay, but how does this help improve our throughput?  On to Step 4;

Step 4: Elevate the system’s constraint. To elevate the constraint of QA could mean hiring more QA folks to elevate their capacity. But elevating the constraint also means we might want to look at offloading some of the responsibilities of QA to other resources that are underutilized like the recently underutilized Devs due to Step 3 above.  Now I think we are getting somewhere.  But before you conclude that we are going to ask Devs to do QA testing, please keep reading.

Getting to Root Causes

Let’s look back at the assessment table again. One of the things that should have jumped out at you is that the team has not consistently had Acceptance Criteria for each User Story.  That’s a bad process smell.  Let’s dig in a little deeper there.

This is what effective User Story Acceptance Criteria does to enhance the development process:

• It helps set up the boundaries for the scope of a User Story (User Stories tend to be very small in terms of scope so clearly establishing the scope of a story is important)

• It lets the Developers know what is going to be expected of them in order to complete the User Stor

• It lets QA know what to test

• It lets Developers know what QA is going to be testing (ah ha!)

One of the problems we found is that QA and Devs were out of sync in regards to the scope of Users Stories.  This caused some churn between the two groups as they were too often debating what was in scope and out of scope for the User Story being tested.

But even more importantly, we found that Devs, because they were driven by the current system to get as much code written before their code complete date rather than get stories completed (signed off by QA), didn’t always test their work before they said their User Story was Dev Complete.  Defects that could have been caught by developers by testing against the User Story’s Acceptance Criteria would have prevented a lot of defects from being passed on to QA.

Conclusions

In order to break our current system’s constraint, we have made consistent and effective Acceptance Criteria with our User Stories a top priority.  We have also included developers executing the Acceptance Criteria before they ask QA to sign off on the stories as part of our Definition of Done for a User Story.  This will result in fewer defects making it to QA and therefore reduce the overburden on QA.

But let’s get back to the original question: what about Unit Testing?  Our assessment found that a lack if Unit Testing was not a constraint in their current process. But that doesn’t mean we aren’t going to address Unit Testing as we all know that there is tremendous value in Unit Testing.  Not only will Unit Testing help in catching defects, it will also help make for cleaner code design and self-documenting code, both of which will eventually address potential upcoming constraints if the constraint in the system moves to Developers.

So, while we are focusing on Acceptance Criteria we are also encouraging and coaching teams to start doing Test Driven Development (TDD). But we won’t be measuring code coverage quite yet.  You recall the adage ‘You get what you measure’.  If we start measuring Code Coverage then we may lose focus on the real system constraint.  We’ll start measuring Code Coverage when it makes sense, but not right now.

Three Faces of Power

1. Decision Making – The power to make and implement decisions

2. Non-Decision Making – The power to set agendas and therefore limit what is even being discussed

3. Shaping Desires – The power to manipulate what people think they want

Lukes’ work is an extension of Max Weber’s Three Types of Authority, in which Lukes argues that Weber only focused on the first face of power, Decision Making.

Others such as Kenneth Boulding have described these power dynamics as the carrot, the stick and the hug.

Regardless of the names used, by simply being informed about these types of power you can become more aware of your surroundings.

The Engineering Manager ordered the Developer to change his task estimate.

An order from a Manager to a Developer is the most public form of power and is an example of how the Manger wants to be perceived. This first face of power is rather easy to spot and diagnose.

This meeting lead by the Director of Engineering only had task estimation standards on the agenda.

A Director who is controlling the meeting agenda is a bit more subtle and requires a level of awareness to see. What is it that they hope to accomplish by limiting the agenda in such a fashion? Limiting the agenda is a technique used to prevent issues that could cause opposition. Do they address issues if they arise in the meeting or do they misdirect? The second face of power tends to leverage delay, inconclusive questions and bureaucracy to avoid the needs of the weaker team members. Sound familiar?

The CTO convinced his team that accurate task estimates are the key to hitting quarterly goals.

A CTO who has convinced his management team that his interests are in their best interests is far more difficult to identify and diagnose. It isn’t always obvious that the actions of the team are a result of coercion from their boss. They can convince people that their wants and needs are actually harmful to them. This third face of power is often aligned with ideological institutions.

These are just a few examples of the faces of power you may experience every day in a large organization.

I believe that being aware of these faces of power help me become oriented during an organizational transformation. Perhaps you’ll find value in them as well.

We then got talking about Peter Weir’s 1989 movie, Dead Poets Society, starring Robin Williams and Ethan Hawke. In the movie, Robin Williams plays an English teacher who fosters a love of poetry in his students and encourages them to demonstrate freedom of expression and a willingness to go against expected norms. The movie takes an unexpected turn when one of the students commits suicide. The kid wasn’t free to live his own life but was being forced to live up to his father’s expectations and dreams. The father wanted his son to become a doctor and viewed poetry and drama as frivolous activities keeping his son from the real matter at hand — preparing for a future in medicine at Harvard. The son, in frustration shoots himself with his father’s gun.

So, the question is, whose fault was it — the dads for forcing his expectations on and disregarding his son’s feelings, or the teacher’s for introducing the concept that when faced with conformity, it is your responsibility to stand up for what you believe is right and to not blindly do what others tell you is just.

Recently I ran into Joe, a tech lead on a big Agile project I had coached. Joe is easily one of the best senior developers at the company, is enormously respected by the other developers and by the business stakeholders he interacts with. Joe has also done a stellar job on the Agile project and has been crucial in keeping multiple project teams functioning smoothly.  However, Joe got dinged on his just concluded annual review. IT management expressed dismay at Joe’s “lack of communication” and “poor planning.” What was actually meant was that IT management was not happy with Agile, was not happy with the business being part of the team, and was not happy with their inability to get ahead of any bad news and spin the message to the business — Joe’s superiors considered transparency to be a very very bad thing.

In this company, the C-level folks have utterly failed in convincing their subordinates that they truly believe in what they are espousing and have failed to create an environment that values and rewards openness. Thus far, senior IT managers have only paid lip service to changing the existing assessments, metrics, and reward systems that encourage lying and hiding material information. Employees believe that to be successful in this organization you need to keep a low profile, not stick your neck out, and to lie and shift the blame to someone else anytime something goes wrong. Senior IT managers have also failed to create any new experiences that would cause people to question and challenge their existing beliefs. Senior managers take their cue from C-level managers and try to do what they think their bosses actually want. I don’t blame them for simply going through the motions; after all, past experience has taught them that there is no benefit in doing something counter to what your boss expects (irrespective of what he/she says).

So, once again, the question facing me is: is it right for us to coach teams and get them dreaming about possibilities knowing fully well that they are not going to get real support and encouragement from their bosses, who say one thing to their business counterparts but do the exact opposite and have no interest in changing their modus operandi? Is it ethical for us to show people the great things that are possible and then have them penalized for their good work?

Have you faced a similar situation before? What did you do? What do you think is the right thing to do — call people out on their hypocrisy? Part ways with the client because long-lasting meaningful change is not a possibility at this time? Spend even more time on educating management and executives?

“not after-the-fact rationalization or a good story designed to hide failure. It is a rigorous method for demonstrating progress when one is embedded in the soil of extreme uncertainty in which startups grow. Validated learning is the process of demonstrating empirically that a team has discovered valuable truths about a startup’s present and future business prospects.”
Ries, Eric (2011-09-13). The Lean Startup (p. 38). Random House, Inc.. Kindle Edition.

At first blush it seems this concept is just made to be utilized by teams working in an iterative manner. They can define sprints, validate learning, and adjust course. The challenge is that validated learning is more than just conjecture or forecasts, this means we must align the product of sprints with empirical, measurable goals. Enter the sprint goal.

More Than Just a List of Stories

When I first started using Scrum, the team I was on had the concept of a sprint theme or goal. Unfortunately for me, at that time I didn’t really appreciate the power of this concept. In fact, we just used it as a summary or aggregation of what was being worked on for the upcoming sprint. “Hey it looks like we’re doing a lot on the search component this sprint, I guess the theme for this sprint is to enhance search”.

This is a common concept I still see many teams do, and it is not without merit. Product backlogs can quickly include hundreds of stories for a given release, and productive teams may complete so many even in an iteration it can be easy to lose the forest for the trees. The simple construct of themes or goals by iteration help people outside – as well as within – the team get a general idea of what’s going on and when. It is a useful tool of abstraction that can help us organize our work. However, if we simply use the theme or goal as a summary of what we already laid out, we’re massive amounts of value on the table. Let’s look at an example.

The product owner of a team I was working with was quite worried. They were building a new reporting system and progress was very slow. The technology they were using was incredibly old, and they were constrained to it for the time being. He wanted to make a release in about six months time, but was unsure if they could do it. After a couple sprints, he said he wanted a realistic approximation of the team’s ability to build one self-serve report from beginning to end. Earlier iterations had been less successful as the team was doing research for other capabilities within the system, there were some technical issues to work through, hardware to procure and some other distractions of that nature.

The product owner cut through this ambiguity by simply stating that for one 2-week sprint, he wanted the team entirely focused on one report. The goal was to see if the team could build one report from beginning to end in the sprint; everything else could wait. His motivation for doing this was to see if the plan of completing a series of reports within the timeframe outlined was even realistic. There were some 20 reports and if the team couldn’t get to a pace of nearly 2 reports an iteration, they had no hope of completing the project with this technology platform. The sprint commenced, the team worked heroically, but by the end, they were unable to complete the report to the product owner’s satisfaction. They had validated their fears that the old platform was too brittle, slow and encumbered by patches and technical debt to allow them to work at the pace desired to make the goal. Nobody could justify the failure or couch it by saying the were working on other things, they put all that to side for validate the fastest pace they could achieve. This is not to denigrate the team, or even the outcome. They learned a valuable lesson and abandoned the release, rather than throw good money after bad.

Now here’s where things get interesting. The product owner was a creative person, and money was already budgeted for this team to work on this project. While they couldn’t build the self-serve reporting system he wanted, their mandate was really one around cost savings. The company had presumed the self-serve system would deliver those cost savings, but now it had become clear that the cost of building such a system would not be justified by the value of the savings. Fortuitously, in an earlier sprint the lead architect had played around with a tool that automatically compiled reports form a series of spreadsheets. This may not sound like much, but the business unit the team was trying to support spent an inordinate amount of time compiling large reports for major customers. The process was tedious, error prone, and sufficiently expensive that they could only product regular reports for large clients. This tool the team had tinkered with briefly had the potential to automate that compilation process. I knew this team was destined for great things when the product owner asked me, “what’s to prevent me from pursing this other avenue?”. I replied that he had justified the investment and he was ultimately accountable, so if it delivered value, then nothing was standing in his way. He was quite excited and set a new goal for the next sprint.

The team believed the tool could be used to automate the compilation of reports that the business produced, but this was still conjecture. The goal for their next sprint was to validate that the tool they had used could indeed produce these reports. Based on what they learned, they would decide if this solution was worth pursuing or not. Based on this goal, you can imagine that sprint planning looked a little different. The product owner was less concerned with bugs and documentation. Several components from their “definition of done” were relaxed as the real goal was to see if the technology would work and perform in a reasonable time. With that in mind, the team chose the most important parts of the system to deliver in order to validate that learning. They constructed a proof of concept system that would be limited in configuration, error handling, and functionality, but it would consume actual spreadsheets from the business and produce a report in the same format as those used by the business. At the end of the two weeks, they were able to demonstrate that, while the system was a little cumbersome to use, it could produce a report from the data the business would use and it could do it quite quickly. The team pivoted to build a production ready version of this system.

They rebuilt their product backlog to deliver a system that would compile reports from spreadsheets and product high quality polished reports according to some predesigned formats. They were able to complete the project according the original timeline and the time savings it delivered met the initial goals of the project. To make matters even better, the cost of producing these expensive reports was lowered sufficiently that the business could offer them to all clients without changing their staffing model. The project was a great success, but I can’t help but wonder what would have happened if not for the critical activities of those two sprints.

Two Goals, Two Types of Learning

Looking at this example, we see two types of learning. In the first instance, they set a goal to test their pace. Based on their demonstrated pace, they made a decisions about their ability to deliver a project according to a projected schedule and budget. They effectively “failed fast” because certain assumptions were invalidated, namely that they could build self-service functionality at a rapid pace in the old technology platform. In the second case, we see learning about the product. They decided to try a new approach, for which limited business analysis or technical research had been done. Instead, they set a goal for their sprint of building enough to answer the necessary business – can they produce the same report? – and technical – will it be fast & automated? – challenges. In both cases, we see that the goal was instrumental in planning and scoping the sprint.

In the first case, the team decided intentionally to not work on anything other than the report. This was because they were still doing some general set up and other supporting activities. They presumed that eventually that work would go away, so if the goal was to see how fast they could build a report without distractions, they deferred those things to run a more realistic test. They even reduced due diligence and preparation of work for successive sprints so they could completely focus. They had strict guidelines about overtime; if their baseline incorporated people working extra hours, that would become expected going forward. In the case of the second sprint, the goal was focused on a specific deliverable to answer questions of fit for purpose. They were more interested in a technical proof of concept that addressed a couple key areas. The Scrum concept of “potentially shippable” code was discarded, they weren’t trying to get something to market yet, they were trying to get something to answer questions, and fast. If the technology worked, the product owner had a lot of selling and justification to do in order to make sure his own sponsors were comfortable with the change in course.

From this perspective, we see that a good iteration goal can help in a couple ways. If provides laser like focus on meeting real goals, this helps focus the team on what’s really important, and helps protect against the mindset that we need to build everything so it doesn’t really matter how we get there. Additionally, focused goals help a team confront risk, validate assumptions, and expedite learning. Properly used, a sprint goal is a very powerful tool.

The High Hurdle of Validated Learning

I must confess this entire experience occurred for me long before the concept of the Lean Startup was articulated as it has been today. I didn’t coach this team with the idea of validated learning up front, but let’s take a closer look to see how it holds up. Validated learning has some rigor behind it to protect a person, team, or company from simply justifying failures as important learnings. Rather, it requires validation that can be demonstrated empirically, which in the case of a start up means customers. Ries tells some very compelling stories of start ups testing assumptions with key metrics that can prove or disprove them. For example, in one case they were redesigning the website to try different marketing messages. They literally ran two simultaneous sites with different copy and messaging. Potential customers were randomly directed to one or the other. All the while, they were collecting conversion metrics for both sites to demonstrate empirically if one was working better than the other (Ries, p. 51). As a consultant who works mostly with large organizations in established markets, this introduces some challenges for this concept. We are still in an uncertain area, but many of these organizations sell to businesses are part of long term relationships producing far fewer data sets. Or in other cases, like some of the self serve tools we discussed, the capability is offered internally or to an existing customer. How do we validate our learning in these situations? Let’s take a look at some assumptions and key metrics.

In this example, there were two key assumptions that were tested:

1. The team can build at a rate to justify our current cost projections (6 months) – this was ultimately tested by looking at the team’s velocity, as well as a focused sprint to see if they could build one report. In both cases, the metrics showed this was an invalid assumption, which would call into question the ROI calculations for the project.
2. The team had a tool that could automate the compilation of reports that were currently put together manually – this was tested by a proof of concept version to create a PDF report in the same general format by pulling data from the spreadsheets and extracts the business already used. The team specifically measured the number of touches to run the process, the run time, and the ability to format the output. Ultimately, they were able to demonstrate a working version after their first sprint exploring this goal.

However, as I look at this situation, I see several leaps of faith and assumptions that were never validated in advance

• Providing a self-serve system to customers will reduce calls for ad-hoc reports: this was the overall business case for the original project. In the end, it was moot, as the team demonstrated they were not able to build the product at a rate to justify further investment. However, I can’t help but wonder what would have happened if they were able to go faster. Would customers have used these reports? Would we only have found out after the project was over?
• Providing an automated tool for compiling reports will save time for members of the business unit: the water is muddier on this one. While the team did work with business partners and talk about if this would be useful. They never produced a definitive measure to empirically demonstrate that it would be valuable. As it turns out, the team was able to finish this deliverable in under three months, so the risk was tacitly accepted. Looking back, I do wonder if there was a way we could have more deliberately validated this assumption.
• Smaller clients want these reports as well – this was an accidental discovery, and no one ever made an assumption about it until the functionality was available and some members of the business unit started offering it to small clients. In the case of this situation it was probably also moot, as the system only took 3 months to build. Had it been longer, the team would have had to devise a simple test, perhaps offering the report to any client who formally requests it. If nobody even asks for it, then they may not see value. Or, manually create the report for a couple test clients and see if they find is useful and want to continue to receive it.

It may be find that we didn’t validate those last set of assumptions. In one case, it was rendered moot by the invalidation of another assumption, and in the other two, the exposure was only 3 months, which the team deemed to be a manageable risk. The concept here would be to identify the assumptions and then methodically figure out ways to validate the most important, riskiest ones as quickly as possible. Considered another way, we could consider this approach to be the scientific method applied to projects. We make a hypothesis, figure out how we can test it, and then we test it. Thus, our confidence in validated learning would be related to our ability to identify valid measures that would prove or invalid the assumptions we have made in our project. While the lean start up model is focused largely on using this approach for product discovery, it could apply equally well to questions and assumptions around execution like the test the team ran to test their rate of delivery.

Getting Back to Sprint Goals

It’s probably worth reflecting on the idea that, while user stories have become the medium of work in most agile projects, they are not intrinsic to Scrum. I have not posed these questions to the creators of Scrum, but I would suspect when they first thought about planning sprints, they imagined something more like the model of validated learning than the model of taking a bunch of user stories or use cases and seeing how many would fit into the next cycle. So, with this in mind, how would we apply this concept of validated learning to agile projects and sprint goals?

Validated learning requires methodically and empirically testing each assumption underlying your project as quickly as possible. The thinking going that the sooner you can validate your assumptions, the sooner you know you are doing the right thing. Any work beyond the bare minimum needed to validate an assumption is potentially waste, because if the assumption is invalidated, then chances are that other piece of work won’t be needed either. If we look at the example of the team building the self-service reporting application, once they realized their pace was so slow they would not make the time and ROI expectations, all the work done to build out that system was discarded, thus any more than the minimum to realize it wasn’t viable was excessive effort. In the traditional agile project, we see a product owner prioritizing based on their perspective of business value. In this model, we see the product owner identifying the key assumptions and then prioritizing which ones should be answered first. Then, the team would set goals for sprints based on the bare minimum to validate a given assumption. The act of defining a sprint would be driven based on the question, “what’s the fastest way we can validate this assumption?”

Let’s take an example. Imagine we’re building an online financial research website to take on Yahoo finance. Our website is going to be better, because we’re going to incorporate the ability to relate the research to your stock portfolio. The traditional agile approach would build a thin line through the system and figure out our bare minimum to launch. We would need quoting, charts, historical information, you name it. We could outline and prioritize the stories to build our vanilla financial service website as the “bare minimum” is more important. In this model of validated learning we would want to home in on that key assumption, that people will use the new website based on the integration of stock information compared to your portfolio. That is a huge assumption and its not clear our bare minimum to launch system will even test that. Perhaps the better way would be to start conjecturing some ways to test that hypothesis with empirical data. Perhaps a widget that would be embedded in a financial broker’s webpage. Perhaps we just build functionality around a watch list, because we presume that a watch list would be used the same way someone’s portfolio would, although that in itself is another assumption we’ll have to test later. Thus, the identification and resolution of assumptions becomes the prioritizing and organizing vehicle behind the entire backlog and each individual sprint. In fact, in cases where a company may exist in an established market, preventing them from launching the full system until it meets a certain threshold of capability, may make the case for validated learning even more. Teams may start by prioritizing based on assumptions, and then at some point pivot and then focus on prioritizing for delivery on a validated strategy. Indeed, if we look at some of the ideas from other thought leaders in the agile field, several people seem to be converging on this:

• Alistair Cockburn discusses prioritizing a project first on learning, and then on business value
• Mike Cohn discusses measuring and burning down a project’s risk profile

The Art of Assumptions

Unfortunately it seems we have opened one door only to find more. Looking back at some of the projects I’ve worked on, I can see huge merit in this approach of building a backlog and iterations around validating assumptions. However, now it begs the question how do you identify and prioritize assumptions. If we identify assumptions, what happens if we can’t come up with a plan to test one of them within the time box of our iteration? Much like good teams need to learn how to slice stories and functionality, good teams will need to learn how to slice assumptions in to progressively smaller and smaller tests so that they can maximize learning. The fact that a team can’t demonstrably test and validate an assumption may also cause some question about the overall capabilities of the team. One of my favorite non-technical examples is the Kiwi boat “Black Magic”, which won two Americas Cups based on a model of two boat design. The ship builders and designers used two identical boats, one as a control and one as a variable. They would make a single change to one ship and then race the boats. If the boat with the change won, it was incorporated into the control design and they repeated the task. This went on for six months, and the team achieved a velocity of validating over a six physical design changes on a fair weather day (Michael Schrage, Serious Play, p. 182). In order to achieve that turn around they had to change the way they built boats. They brought the ship designers into the shipyard to streamline communication and also had to bear the up front cost of building two identical boats. Likewise, you may find that your team requires investments and changes to the way it operates in order to rapidly validate learning.

These questions will have to wait until another day. For now, even if we are not yet able to articulate all of our assumptions with ways that they can be tested, we can begin down that road by identifying clear business or execution goals for a sprint. Just this simple step would give us a clear validation, where we could ask, “are the stories we’ve identified the bare minimum to achieve that goal?”. It may also increase our feedback, as soon someone will start asking how you’ll even know that goal has been met. At that point, you’ll be well on your way to getting validated learning.

• What went well this year, or what did I do well this year that contributed to my personal, professional and company’s success in 2011?  Celebrate these successes and consider ways to leverage them in 2012.
• What wasn’t successful and I should try to stop doing or do differently?  Celebrate these attempts, laugh where possible and leverage what you learned in 2012.
• What changes am I going to make or try in 2012 to improve my results?  Focus on one or two things that you believe are important to try.

Now consider what you’ve done, learned and will try relative to the challenges you know are ahead in 2012.  Planning or strategizing for the nearest challenges in the New Year relative to what you accomplished and learned in 2011 will provide some guidance on the first steps you should take.  Additionally, here are three things for you to consider as you begin to think about the work ahead:

Alignment – Is there alignment between your customers needs and what you are delivering?  Is there alignment or agreement on goals?  Is there alignment between your personal and professional goals and what the company needs to be successful?

Transparency – Be open, honest and respectful in communicating and delivering what needs to be accomplished, why it is important to accomplish and how it will be accomplished.  Alignment is not possible without transparency.

Success – What does success look and feel like to you?  Create your vision of what success feels like and work with your team, your management and your peers to create a shared vision of success to help guide the organization.

I have often found that creating a shared vision of success for a team provides a compass for a team as well bringing the team together to work collaboratively towards a goal.  Understanding the organization and your client’s needs begins the necessary step of aligning priorities, and determining how best to meet the challenges.  Finally supporting and enabling transparency helps create an environment where the team can self-organize, where the learning process is valued in determining how best to solve a problem and collaboration can be improved, ultimately improving delivery.

There were two reasons for the request:

1. I recently critiqued a 2-day “Introduction to Agile” class by a coach-in-training. Everything that I expected was covered in the class but I felt the lack of an underlying theme; the content didn’t seem to fit well together.
2. I wanted to understand whether Agile meant the same thing to different people and whether they emphasized the same points in their class/presentation.

Here is a sampling of the responses I received.

• “Deliver value frequently at a sustainable pace while adapting to business needs.” — Brad Swanson
• “Be one with the customer.” — Steve Johnson
• “Sense & respond quickly to changes that have measurable value.” — Skip Angel
• “Do the right things sooner.” — Jonathon Golden
• “Agile is about knowing what NOT to do.” — Mike Dwyer
• “Continuously adjust our actual process to reflect our improved understanding.” — John Ryan
• “Utilizing continuous prioritization and feedback, collaboratively develop incremental business value.” — Jim Elvidge
• “Continually improve value delivery via experimentation, feedback, and retrospection.” — Alex Singh
• “Do Something, Self-Organize, Inspect & Adapt” — Scott Dunn (stolen from Aaron Sanders)

Not surprisingly, people emphasized different aspects in their distillation. I assume that these are the same things they emphasize when coaching teams and organizations as well. It is important to note that everyone is right and no one definition is better than another; people with different backgrounds emphasize different things and have a different worldview.

What do you think is the intrinsic nature or character of Agile that makes it what it is? How would you define the most important aspects of Agile in no more than 10 words?

Edgar Schein is a former MIT professor at the Sloan School of Management and author of numerous books on organizational development, the consulting process as well as other subjects. Schein’s work is based on over forty years of consulting experience. He is also generally regarded as the originator of the term ‘organizational culture’.

Schein views the consulting process as essentially a ‘helping’ relationship between the consultant and the client. He gauged each interaction with a client by the degree that the relationship had been helpful and whether or not the client felt helped.

I found Schein’s list of ten tips on creating and maintaining a helpful client relationship to be directly applicable to our work as coaches and essential to helping us create and maintain great relationships with our clients. I have included Schein’s list below along with one additional tip and a bit of personal commentary.

1. Always try to be helpful – Coaches have to know when to help, how to help and learn to see what the client is really asking.
2. Always stay in touch with the current reality – this could be the most important principle because it is really about being mindful. Staying present and aware of what is happening here and now is one of the most fundamental skills that a coach should develop and the key to performing well with all of the other principles listed here.
3. Access your ignorance – asking ourselves what we really know vs. what we think we know is an important exercise for coaches and one that can help keep us grounded and in touch with what is happening now. In other words, question your assumptions.
4. Everything you do is an intervention
5. It is the client who owns the problem and the solution
6. Go with the flow – if you remember principles one through three you should have not trouble with this one
7. Timing is crucial –Finding the proper moment to bring up a sensitive subject is crucial to building and maintaining a helpful relationship with your client.
8. Be constructively opportunistic with confrontational interventions – there are times when clients are more likely to respond to intervention. Be patient and wait for the right time. Any questions see principles two and seven.
9. Everything is a source of data; errors are inevitable – as Schein says, we all make mistakes. We, as coaches, have to accept the fact that we make mistakes and do what we tell our clients to do – learn from them.
10.  When in doubt share the problem – this one is about coaches helping each other, which is something that we do continuously at Big Visible.

I really like this list and find it helpful to refer back to it occasionally. However, I would like to add one of my own…

11) Set expectations up-front and adjust as necessary – your personal preferences and coaching style and that of your client’s will contribute to the specifics of this conversation, but suffice it to say that open, authentic, conversation about expectations is essential at startup and throughout the process.

In software development, however, the technique has some shortcomings:

• Problems and their causes are not always linear and you cannot always trace a symptom directly to a root cause by asking the 5 Whys.
• Sometimes causes are separated, in a significant manner, by time and space from the effect; this makes identification of the relationship difficult.
• Practitioners at times aim for the single root cause, but each question could elicit many possible root causes.
• The 5 Whys technique works well in simple and complicated environments; not so well in complex and chaotic conditions (see the Cynefin framework for definitions). Multi-causality, contributing factors, and not-so-obvious variables if ignored can lead the questioner to the wrong conclusions.
• Results are highly dependent on the questioner’s ability — stop too soon (at the symptom level) and you don’t reach the lower level root causes; stop searching after the first right sounding answer and you miss out on other plausible causes; treat a long-lived and unchallenged statement as fact and you limit avenues of investigation.
• The questioner’s level of knowledge is a limiting factor — ignorance can cause people to overlook causes they don’t already know about.
• Results aren’t repeatable and different people can identify different causes for the same problem.

It’s important to realize that we have more than the 5 Whys method in our toolkit. We can flow chart the process, use the Current Reality Tree (CRT) thinking process, or use Gerry Weinberg’s Diagram of Effects (my favorite). Which techniques do you use?

Step 1. Lead from the front using the leader part of servant leader. Use this when the team is lost, going off the rails or about to run back into the burning barn of traditional project management.  As soon as the team gets their bearings, starts being honest with themselves, or chooses not to get burned again, move immediately one step back and to the side.

Step 2. Coach from the side. Be there on the sideline giving support, offering suggestions and providing guidance. Shift to Socratic method.  Once the team gets their confidence back, take another step back, moving behind the team.

Step 3.  Mentor from the rear.  look for patterns, learn how the team(s) are moving ahead through their challenges so you can lead them when they ask for help.  Remember you are now a firemen always ready to go when the team rings the bell.  When you get to the fire you’ll know which steps to take.

New research leads me to believe that we may be collectively suffering from ego depletion.

Ego depletion is the idea that self-control or willpower is an exhaustible resource that can be used up. Interestingly enough, sugar (or glucose) intake helps us prolong our ability to make decision after decision throughout the day.

Initially it sounds far fetched, until you think about all of the decisions you make throughout a work day and how they correlate with your sugar intake.

Consider the number of decisions you had to make in order to get to work this morning. Now once you’ve sat down and booted up your machine, imagine how many decisions you make before you start to even code. After you’ve started coding (or writing your tests if practicing TDD) imagine how many decisions you continue make in the span of just 1 minute.

If you do the math you begin to realize that you make a staggering amount of decisions throughout the course of just one work day. Many of these decisions are under pressure with serious implications.

In addition to ego depletion, research has found that these decisions can be broken down into pre-decision and post-decision processes.

A prolonged period of pre-decision is not ideal for a team that thrives on quick feedback loops.

I believe we can use this new found research to help our teams be in situations where they can make the best decision possible.

Daily Standups - Urge agile teams to have the daily standup in the morning if possible. It is our daily plan and we need our team focused as we make decisions on what we are about to do.

Retrospectives - Bring candy or snacks into the retrospective. Team members are more likely to forget their manners when suffering from ego depletion. It isn’t just people, it even happens with man’s best friend too.

Iteration Demos - Schedule these early and bring muffins, donuts or pastries along with some form of juice. If the Product Owner is accepting the work, he or she needs to have the mental fuel to make the tough decisions.

Feedback Loops - How long does it take to compile and run tests locally? How long does it take to deploy a build to test or production? How long does it take to get an answer from the business on feature question? All of these affect pre-decision time spans and deplete willpower.

I believe if we can align our agile and scrum coaching techniques with these findings, the result will be a team that is in an environment where they can repeatedly make good decisions.