Agile Forest

Find your path to agility with Renee Troughton

Is Agile dependent on culture or leadership support for success?

I recently read Silence by Shusaku Endo. It is a book about the early missionaries to Japan in a turbulent time when they were not wanted (to an extent that they were actively sought out and tortured).

As I read the book I was reminded of the analogies that Agile often has from its critics that it is a cult or similar to a religion, and as I read the book I changed the language and words in my head to see to what extent it fit against the criticism.

One page in particular stood out for both its beauty and applicability. I would like to share it with you with the words changed to Agile to see your thoughts on it. Think of it with a lens on the success or failure of transformations:

(Page 117)

“A tree which flourishes in one kind of soil may wither if the soil is changed. As for the tree to Agile, in a another company its leaves may grow thick and the buds may be rich, while in this company the leaves wither and no bud appears. Coach, have you never thought of the difference in the soil, the difference in the water?”

“The leaves should not wither; the buds should appear,” said the coach raising their voice. “Do you think I know nothing? People are familiar with the work of the Agile community; and it is well known that when many projects gave permission for evangelization the number of Agilists reached three hundred thousand.”

The old man constantly kept nodding, all the time rubbing his hands together. Whilst the other managers with tense expression were listening to the words, only the old man seemed completely on the side of the coach. 

“If the leaves do not grow and the flowers do not blossom, that is only when no fertilizer is applied,” the Coach said.

The analogy here that management support is the fertilizer, that culture is not the differentiator to success or not.

Do you feel that the tree would flourish regardless of the soil and water?

This is an interim blog post defining my thoughts whilst attending the five day Holacracy Practitioner Training in Philadelphia. I will probably repost my final thoughts or add some comments when I return back to Australia.

So why do Holacracy Practitioner Training in the first place? It certainly wasn’t because I had client that had an appetite. It was because I wanted more depth on the logistics of how it worked after reading the book a few years ago and after hearing a few people from zappos and other institutions talk about their implementations. I wanted to hear the tips and tricks from the expert and creator, Brian Robertson. I also wanted to do it because I felt that it would be the logical next step for organisations after or mid Agile transformation, especially those that had tried self selection, so I wanted to prepare myself for the future.

What I got was all my desires and more. For the logistics of how it works, the five day practitioner course really is practice focused, with a complex simulation that enables multiple opportunities for everyone to fulfill the facilitator and secretary roles in a very safe to fail environment. As for hearing about zappos and other institutions, well I haven’t heard much about Zappos yet, but I have heard from a lot of people on the course about how it is going in their organisations. The number of attendees already doing Holacracy somewhat surprised me and some of them already had a few months experience up as facilitators (and it showed). I have found that I have gotten as much value out of the people attending the course as those running it. I have enjoyed watching some of these people who have had honest concerns that they are still on the fence about the value of Holacracy change over the course of a few days – often because they didn’t understand the purpose of a particular activity, but more commonly because it was being implemented incorrectly (because this never also happens in Agile transformations right?).

As for Holacracy being the next logical step past Agile, well I am really not sure about that now and probably need more processing time on that one. It certainly isn’t a pre-requisite (though I never thought it was), but I don’t think people early in the Agile journey have to rule it out either (where I once thought maybe mindsets may not have been progressed enough for this leap).

So for some more detailed thoughts on the course, in a somewhat time based progression format feel free to read on:

Day 1

  • Introduction of theory was expected but felt long taking up most of the first morning.
  • Brian really is as engaging in person over a long duration as he is talking in videos. His energy is quite infectious.
  • Afternoon session – simulation. Now I build games for my training so I know the value of a good simulation and this simulation is the second most complicated one I have ever experienced (Lean car factory being the most complicated one I have). As we went through the simulation I guess I had the unique perspective of not just doing the activity but also analyzing at the same time the simulation itself for the outcomes expected, the constraints and the rules. Now when I build games I build them so they fail first, which this does. But I don’t build them with so much failure that the goal  is 100% unachievable – that is, if you are a master, you might still succeed. The Hygean game – well it was built with a 100% failure rate. I could tell very early on what the constraints were, I also had a good background in the simulated value chain so I knew that well. From minute zero of the game I began working to the roadblock of the delays in the value chain. But when the constraint never responded in the first round at all it meant that value was never a possibility. Now I realised in the evening of Day 1 that I had made two incorrect assumptions about the simulation – that value was important (ie the business not running out of money). Lean thinkers will see very quickly that the business is about to run out of money, but it is a bit of a red herring, in some ways the simulation doesn’t reflect reality because people would care a lot about this information. The second assumption was that it mattered to win (ie successfully deliver value). It doesn’t, the point of simulation is to arm yourself with enough ammunition to run through the governance and tactical meetings, nothing more.
  • Checkins. They feel really clunky. I’ve never been a huge fan of them because I have seen them abused in the past but they did feel authentic in the meetings we had.
  • Building agenda items – the usage of only one or two words for an agenda frustrated me. I can see the similarities of the activity to lean coffee, but unlike lean coffee, where you spend fifteen to thirty seconds talking about your agenda item, in holacracy there is zero time spent on what the agenda item means. The consequence is that no one actually understands the agenda. This felt incredibly uncomfortable, mainly because I wasn’t quite sure if someone else’s agenda item was similar to my own as the two words were the same and so I didn’t know whether I should raise my agenda item. What I subsequently resolved that evening was that it didn’t matter. It was my responsibility to put my agenda item up regardless. The agenda item is only a refresher for the single individual that created it and nothing more.
  • Reaction round – the process in a lot of respects feels like the Cynefin Ritual Dissent activity – in that it creates space for a proposer talk without interruption, that respondees can ask questions, respond emotionally without interruption (with a small element on Non Violent Communication) and with dissent. After that it is more like a facilitated processing activity with similar restrictions on who can talk when. In the scenarios that we went through I found this activity at first incredibly frustrating, not because of the process, but because it felt that there were gaps in the structure of the process. As an example, in our simulation with the financials running out a proposal was put forward to make the financial runway visible to the organisation so that we didn’t go out of business. The proposal was opposed because of a concern that people would leave the organisation if they thought it was about to be bankrupt. This was based upon an assumption that was perceived, but was not rooted in metrics and because the objector felt that the information wasn’t safe to test, it was considered a valid objection. My main concern with this outcome was that the assumption was statistically invalid, just that the objector was not aware of it, but importantly that I had no ability to even say this, that the falsehood of information was allowed to continue unabated. Now in fairness, I now know that if we had time it would have gone to integration and that hopefully that information would have come out then, but it felt like time was being wasted.

Day 2

  • The feeling of a lot of time wasting in these governance meetings continued as I pondered time and again where lean elements of root cause analysis and value stream analysis fit in. People changing roles and accountabilities without any understanding of the value chain seemed inane. But what I realised by the evening of Day 2 was that it didn’t matter – because the value chain would be discovered over time through continual incremental refinement. In essence, getting roles, accountabilities and the value chain right occurs over time (and isn’t ever right). It is like Agile, the software will never be right by the first sprint, but through continual build, reflect and adaption it will get good enough in the end.
  • Proposal tension analysis takes a lot of time when the change is a large merge/refactor. It felt slow waiting for everything to be typed in, but then I found out afterwards that you can propose items in advance and write up all the proposed changes beforehand. This made me feel comfortable that corporates would balk less at the time waste if they knew information could be processed asynchronously (which was demonstrated to me afterwards by someone doing holacracy already).
  • It really hit home to me by the end of this day that tensions are best when they are micro and are frequently worked on. Weekly governance over monthly would be the best way to start, much like short Sprints allow more frequent adaptation. My favorite quote of the day – “Design the org, just in time, for what you need not what you might need.”
  • Not a huge fan of the ’cause harm’ language, prefer the longer language of ‘can impact delivery of the circle’s purpose’.
  • The term ‘project’ also feels like the wrong language to use. Many corporates have a deep tie to this word and I feel it would be better changed.
  • A comment was made (either this day or day 1) that an example of an outcome for a project would be ‘Product page redesigned’ – I would argue that that is not an outcome, an outcome would be the why – ie “Provide a more user friendly experience to increase customer clickthroughs”
  • How to prioritise tensions – strength of tension, first in first out, shared tension or time criticality. The answer is it depends on your needs and almost all options can be used at the discretion of the facilitator.
  • Can the facilitator and secretary be the same person? Yes, but it is not generally recommended. I can see through the simulation why for beginning teams this is not recommended.
  • How do you balance workload if you are working in multiple roles? The answer is holacracy doesn’t specify a solution for this.

Day 3

  • Root cause analysis can happen, but only if the proposer asks for help/it. So if, as a respondee, I am needing root cause analysis to get onboard with the change then it isn’t the proposers problem, it is mine. Consequently the proposers change should go through without objection and if I care about root cause analysis then I need to raise the tension (proposal). Processing tensions is all about processing the tension for the proposer, not for opinionated people.
  • Back to the earlier quote – ‘what might happen’ objections which are invalidated result in only a 10% new proposal rate. This isn’t due to people feeling petulant that their objection was invalidated, but that when it comes down to it, the concerns aren’t really that big of a deal, we are just so used to providing opinions that we can’t help ourselves.
  • Feeling very comfortable with the process and its micro adaptation of the organisation.

Day 4

  • If you are the sort of person (like me) that likes to help someone refine their need (ie paraphrase) then you would feel frustrated with the experience of the governance meeting as you cannot help the person get there. You have to be more patient and accept it will take more time.
  • Tactical meetings – not a lot of new content or concepts in here for Agile folk.
  • Use lead in narratives about the current step so that people understand what they are allowed to do (or not). If people get off track (out of process) guide via “We have space for that comment in the next step,” and then return to the current step.
  • “It is not a valid objection, but it sounds like you have an item that you may want to add to the agenda.”
  •  Today reminded me a lot of Kanban’s rules – start with what you do now, know your constraints, your policies, respect.
  • Tactical tipsheet – if the action is volunteered by a person and there is no role accountable then the action is classified as “individual action”
  • Domain – full ownership for that thing, it no other roles can meddle with it without the express authorization of the domain role owner.

Governance Tipsheet

Present Proposal – proposer can ask for help or root cause, but normally will just be proposer.

Clarifying Questions – NOT a round robin, only people who have questions. Can have multiple questions. Ensure questions aren’t leading or an alternative solution is being presented. Stop people quickly if the question doesn’t start with a “what, how, why, when, or who…” Does not include proposer.  Facilitator can ask questions.

Reaction Round – Does not include proposer (even responding). One by one go around, including facilitator.

Amend & clarify – Proposer only. They can choose to change things based on the reactions and clarifying questions. They can also choose to not change.

Objection round – Have proposer last, includes facilitator. Ask “Do you see any reason why adopting this proposal causes harm or moves us backward. As a facilitator you can jump around the objection questions if you feel there is a hint in what is said as to which objection it may fail on. The goal is to facilitate the process, not have emotions. Ask both sides of the question sheet. Anyone can ask in the integration round for an objection to be re-tested if they felt it wasn’t done.

Integration round – In integration, anyone can contribute as long as the facilitator has no objections and as long as the proposer and objector have opened it up. Ask the objector if they have an alternative proposal that will meet the need of the tension. Once done, confirm with objector if this meets their needs. If both are happy then it is integrated, otherwise it goes back for resolution. Another round of objections occurs after accepted integration.

Day 5

  • Just because you have a need from someone doesn’t mean you can’t talk to someone and ask them to do it. Use the governance process for tensions were expectations are NOT being met…. otherwise you will have dozens of accountabilities.
  • We seem to try to get agreement on the tension before we process it (consensus build). Holacracy accepts the tension regardless in order to process it. In this respect, you transition the time in an organisation spent consensus building outside of meetings to tension processing in governance. The time is likely to be less in the later.
  • Can use ‘curator’ rather than ‘secretary’
  • For Agile areas – keep your retros, have them feed straight into governance. Sprint Planning is often combined with tactical meetings, especially if the circle is the Scrum Team. If the circle has a few extra people outside of the Scrum Team then you may want to split the two.
  • Have governance straight after a tactical meeting as tactical meetings are likely to drive desire for change.
  • Address what happens with compensation early in the selling of holacracy discussions.
  • Existing policies get moved across into the appropriate circle.
  • Use the habit support program in Glassfrog
  • Don’t over do the setup at the start. Don’t be tempted to fix tensions as you breakdown job titles into roles.
  • Don’t give roles very status titles
  • Don’t try both (ie management and holacracy) at the same time
  • Developer role with a focus on product X is better when multiple products need to be supported in an area.
  • Have a role for guild lead, otherwise don’t have circles for tribes.
  • Be clear on how meetings relate to holacracy – stop doing or cut out the parts that are covered by tactical and governance meetings.
  • And for meetings that you keep, be clear on holacracy links – ie what roles are invited, tracking, actions, projects, tensions etc.

Outstanding questions:

  • How is this going in Zappos?
  • Why aren’t there any values/principles in holacracy?
  • How does the constitution change over time?

There is a world of misinformation out there about Agile. Even I have probably created some misinformation once or twice (not deliberately).

There is probably too much wrong to fix, but I saw a tweet recently that I wanted to tackle. It was originally linking to the Segue Technologies blog:

http://www.seguetech.com/blog/2015/11/03/waterfall-vs-agile-infographic

Naturally some people in the Agile community responded and it is fair to say their response was one of confusion and disbelief. Many thought it was a joke, but I suspected that the creators of the information felt it was a reflection of what they believed to be true and not intended as a joke. I tried to seek clarification to which I got a response:

We develop for a wide range of customers. This is a high level info on 2 different methodologies to show non-developers that there are different approaches.

So it was an honest attempt to educate and provide value. Okay. So let me try to give an honest attempt to re-educate on what I perceive to be some of the errors in this infographic:

 

Agile Pros:

  • Customer approval during all stages:
    Probably just a minor clarification, but approval is a little strong for me. They are involved throughout – what that means is that they agree to the work to be done just in time prior to starting it, then they get to see it when it is nearing completion. In essence, there is a greater focus on building the right product.
  • Great for quick launches:
    Okay, but maybe more importantly, Agile is great for getting a product out quickly and getting feedback immediately from customers to know whether you are on the right track. You can continue to build on this product through subsequent iterations.
    I want to take a moment and comment on the usage of the term “customer” through the infographic – I am concerned that it is referring to a customer in the business as opposed to a real customer who uses the product. Also there is a lack of distinction on project and product throughout.
  • Prioritised by business value:
    Business value is important and should definitely be used as one means of prioritisation, but there are often other considerations used in Agile – Weighted Shortest Job First is a classic example of this. For me, in Agile, prioritisation should include consideration of business value, risk (either technical or implementation), cost, cost of delay and learning value.
  • Customer involvement makes project user focused:
    So customer is now distinguished from users (who are the real customers). It may be a little concern of mine, but I do feel the strong focus in Scrum on the Product Owner role detracts us from making greater efforts to get to know the real customers. Yes teams can work hard to ensure they hear the voice of the real customer, but there is nothing like using only customer data to drive your decisions.

Waterfall Pros:

  • Early agreement on deliverables:
    The natural risk here on early agreement on deliverables (and I think they mean scope rather than deliverables) is that as you learn things through development, the agreement is moot. Build the right product, don’t just build the product that you agreed to that meets no ones needs.
    If the interpretation truly was deliverables and not scope, there is nothing stopping you from having a great understanding of what needs to be done upfront with Agile. Many teams that I have worked with do an activity prior to going into iterations called “Inception”. The purpose of this activity is to have a common understanding about everything that needs to be done (as best could be understood with so much uncertainty in the complex world of software development).
  • No need for customer involvement during development:
    I read this like ‘In software development there is never a need to clarify anything or to get feedback on anything’. Yeah, like that happens, or like that works out to be a great solution. In the early days of Agile when I heard this twelve years ago my response to the business when they said they couldn’t afford to have an ‘onsite customer’ was “okay, then if this project isn’t one of the most important ones for us to focus on as an organisation, that it isn’t critical to invest business experts in for, then it sounds like it isn’t critical enough to invest IT experts in.” The response was always swiftly met with the provision of a good SME.
  • Full scope known in advance:
    Never in the world of software development has scope always been fully known in advance. This is just a fallacy and it should be stopped being used by Waterfall appreciators.
    We never build the same thing twice. As a consequence, software development is not a production line, it is a process of discovery.
  • Known deliverables reduce chance of “piecemeal” effect:
    There are so many great tools out there for dampening the “piecemeal” effect of Agile – let me name just a few: Inception, Story Mapping, Impact Mapping and Feature Parking Lots.

Agile Cons:

  • Disadvantages when team is dedicated full-time on the project:
    Firstly, I am pretty sure there is no rulebook that says teams should be dedicated full-time in Agile. I won’t disagree that it is common practice, nor will I disagree that in almost all instance it is a good thing.
    Secondly, I have done some waterfall projects. People were full time in those too, so it isn’t an Agile thing.
    Thirdly, we have lots of great scientific evidence around the benefits of having team members full-time on work – it reduces context switching, it focuses on getting the work done sooner, thereby delivering value to customers sooner, thereby earning money for the business sooner. If you are interested in learning more about the science take a look at “Product Development Flow” by Don Reinersten. Another good book is “Slack” which talks about the misconception around being 100% utilised.
  • Customer may not have time to be involved:
    I guess the project isn’t very important then.
  • Customer may redefine scope:
    That sounds like a pro rather than a con. Especially if it means we deliver the right thing rather than waste money on building the wrong thing. The biggest waste as described by Lean is building the wrong thing – in software development this accounts for 64% of features developed.
    Edit: in trying to be accurate on this statistic I discovered it was based on a sample of 4 projects. Those sample numbers are definitely not enough to prove anything. Well at least I learnt something new.
  • Quick launches can cause incomplete tasks:
    I don’t know about ‘quick launches’. If this means getting a product to a customer can cause unimplemented scope to occur, then yes I agree it can, and that is a good thing – because we can get value and learn from it. It doesn’t mean that we won’t continue to work on the product, just that when the cost of implementing new features exceeds the benefit then we are probably going to stop. That sounds pretty sensible to me.
    Often in Agile environments we try to automate “launching”. The process of automation inevitably should result in better quality of deployment over time (due to the removal of manual errors) rather than creating more incomplete tasks.

Waterfall Cons:

  • Customer only sees final product and could be unhappy:
    In the waterfall projects I have been on with limited customer involvement the ‘could’ has occurred in 100% of instances.
  • Customer has trouble visualising project in early stage:
    This happens with either approach. We don’t know what we just don’t know.
  • Late changes cause going over project budget:
    Again could happen with either approach. Agile projects should reduce or dampen this effect by delivering the higher value work sooner. But I have to be fair, in my experience most projects I have seen (be them Agile or Waterfall) have had overruns of time (not in production delivery necessarily, but overall effort expenditure). Going over project time often means going over project budget. I feel however our focus on budget/time as indicators to success are sub-optimal, but maybe that is a blog post of the future.
  • Late changes extend project timeline:
    As above.

What should factor in your decision – customer preference, project size, customer budget, time to market, customer availability:

  • No, you should just always use Agile. I know this sounds dogmatic and like I am a cool-aid person, but when it comes to mitigating delivery risk there really is no alternative to Agile. If you want to deliver with greater success, less risk and with the greatest chance of getting the outcome you want you need to use Agile, it just really is that simple.

 

 

When I was in Washington for the Agile Alliance 2015 conference I met up with Craig Smith and Christopher Avery for a podcast (unfortunately for me half way through). It was my first real introduction to the Leadership Gift and Responsibility Model. I had heard Craig talk to about the Leadership Gift a few times but the conversation intrigued me.

Recently I have started to have a look in depth about what a fully comprehensive leadership training program would look like and remembering the conversation in Washington I set aside some time to watch the youtube video on The Leadership Gift.

The following are my random notes that I took as I watched the video. They will likely seem contextually disconnected and out off place but I write the notes in the spirit of Non Violent Communications appreciation – to give clarity of what I give thanks for.

So the basic model is as such:

resp_process_big

 

 

 

 

 

 

 

 

 

  • The importance of moving the “inversion layer” eg the layer of management that deals with where teams transcend across coloured layers (as described in Fredrick Laloux’s Reinventing Organisations Book). Eg a green Agile team and amber management – the Scrum Master is the person who is often affected by the inversion layer. The goal should be to NOT have an inversion layer.
  • A reference to complexity and uncertainty (making me think of Cynefin)
  • Accountability does not mean responsibility (resonated)
  • Do we make commitments visible?
  • The responsibility process demonstrates how we use language when things go through (key message)
  • Justify = “that’s just the way it is around here”, “there’s nothing I can do about it” (important classification)
  • Impediments = a conception of elements beyond our control (but are they really???)
  • Responsibility is the place of freedom – of control and power in ones mind (key message).
  • Shame is socially considered a level of responsibility, but it is not (aha moment for me).
  • When we are truly responsible when something goes wrong we acknowledge it but more importantly we focus on what we have done to fix it, to stop it from occurring again and what still needs to be done, or what is outstanding (key message)
  • High performing teams – go beyond their accountabilities, have highly successful outcomes & have a great time doing it
  • Reference to Chris Argyris & Double loop learning (re-hearing what I learnt a few years ago)
  • We weren’t born with perfect knowledge and we won’t die with it either (loved this quote)
  • … but we can learn through experimentation, trial and error (again reinforcing lean startup to process belief)
  • Get off shame by forgiving yourself
  • There is no personal growth when you are living below the line, ie doing obligation, shame, justification, blame or denial
  • What to do? Firstly intention – create a desire to get above the line with free will. Secondly have awareness – a life long pursuit. Thirdly confront yourself – what change is needed based on awareness. (key message)
  • Winning is about meeting an achievement not beating others (similar messaging as Non Violent Communication)
What is a Minimal Viable Agilist?

What is a Minimal Viable Agilist?

I have been doing some hiring lately. The two roles I have been hiring for are a Scrum Master and a Business Analyst. I used the opportunity to test my recruitment questionaire – questions that I am expecting the organisation to ask in the future when I am no longer there in order to ensure that they are getting quality candidates into the roles.

The questions had some basic Agile bits, the sort to ensure that we were getting people who culturally understood T-shaping, the values and principles of Agile – not that they had to ring them off by rote, but they knew and understood what it felt like to experience them.

And then there were the role specific questions. For the Scrum Masters the test predominantly comprised a series of pictures with a question per picture. An example (without showing the picture) was “Take a moment to orient yourself to this wall – what issues do you see with the team/the work?”

If the Scrum Master applicant passed the basic Agile questions and the wall picture questions, stage three was getting them to demonstrate facilitating in a mock scenario.

Somewhat thankfully our search for a Scrum Master didn’t last too long – candidates that recruiters passed through to us all failed abismally. All of them didn’t even pass through the first stage to begin asking the picture based questions. Feeling despondent we did the whole ‘Who do we know who can do the job and are actively looking?’ thing. Interestingly they passed all three components of the test quickly.

So then the challenge was finding a Business Analyst, and that was indeed difficult. We had resumes without even a reference to the word ‘stories’, ‘Agile’ or ‘Scrum’ being put forward by recruiters despite being exceptionally clear that we were looking for Business Analysts who had strong experience in an Agile environment.

There were a couple that got through to stage two testing – but they were few and far between, many of our interviews got cut at 10 or 15 minutes.

It was very frustrating; we weren’t asking questions that were hard – we were asking questions that anyone who cares about being good at their job should be able to know the answers to.

So let me put this as simple as I can – if you aspire to be an Agile Business Analyst, or you think you are worthy of being an Agile Business Analyst and selling yourself as one, then these are the things I feel you should be able to answer (naturally these questions are more fluidic and are asked when a conversational element exposes their relevancy):

  1. How do you decompose something down from a big idea to something that can be delivered by the team?
  2. What qualities does a good user story have?
  3. How do you know when a user story is small enough?
  4. If you had a user story that was too big, what are the different strategies you would think of/use to try and break it down further?
  5. What is the difference between Acceptance Criteria and Definition of Done?
  6. On average how many Acceptance Criteria do you have per user story?

If the answers to the above questions are correct then the interview goes onto stage two – scenario testing. Similar to the Scrum Master test we provide a simple User Story and ask the person to define some Acceptance Criteria. Then we ask them to look at a number of poorly formed User Stories and tell us what is wrong with them.

Stage three, like the Scrum Master is practical, asks for a demonstration of analytical and breakdown skills through a scenario, ultimately to test facilitation skills and on the spot thinking.

Now I won’t reveal the answers to the questions above, but if you feel like giving a try and responding in the comments you are welcome to. Additionally I have left out some of the thinking processes that we have been looking for but I can reveal that answers like “I just do what I did back in waterfall – I talk to people and write the requirements. Business Analysis is no different in Agile than in a Waterfall environment,” is probably not going to get you the job.

But through all these interviews what I was most surprised with was how little people cared about the quality of their skills in their chosen profession. I am often frustrated and don’t know the answer as to why people know so little about their profession. Here are some possible root causes I have conceived of but I don’t know which is the right answer (I suspect it varies based on the person):

  1. I am too busy doing my job to learn how to be more effective in it (too much work)
  2. I work hard when at work, in my down time I don’t want to think about work or read about things related to my job, I just want to relax
  3. I studied at school and for my degree, I was so glad when that was over I didn’t really want to study anymore
  4. I am awesome and don’t need to know any more/get better
  5. I am sick of people telling me what to do and how to do it, I am just going to do the smallest thing I have to in order to get my paycheck.
  6. Understanding this change threatens my job in some way
  7. I get by, no one else has commented on how I do my job

And so the ultimate question that it came down to in the interviews were “What is a Minimum Viable Agilist?” To me it is a person that cares about their craft, that understands the value of spending time to make themselves better and in doing so making the product better.

Firstly I apologise for getting a little slack with my blog. When I do presentations I tend to invest a lot of time in them and consequently a lot of other items get de-prioritised. Since my last blog I have presenting at the Agile Games Conference in Boston, at the HR Game Changer conference in Melbourne and at Agile Alliance 2015 Conferencein Washington. If you would like to take a look at any of my presentations feel free to visit my slideshare page.

I am hoping I will have a quieter six months in order to focus on a few projects such as finishing my Agile Forest Book, finishing a Visual Management book I am co-authoring with Craig Smith and getting a production quality Agile Bootstrap kit together which has Agile posters, cards for the usual ceremonies and cards for a training wall. If you are interested in being involved in any of these projects (ie reviewing or just want to know when they are done) then feel free to contact me at: renee@unbounddna.com.

Speaker_Badge_200pxAnyway, this blog post is to endeavoring to talk about my high level observations of attending the Agile Alliance 2015 in Washington, so lets kick it off:

  • It was my first foray to this conference. Comparing it in size to Agile Australia which has over 1000 attendees, Washington has near the 2500 attendee mark. Despite this, it didn’t feel like an impersonal event. With sit down lunches, dinners and breakfasts, round tables and activity filled sessions galore and lots of open space to have conversations, I felt that there were plenty of opportunities to get to know people that I have connected with on twitter, but also new people that I have never met before.
  • Conference venue was great, I loved the natural light in the corridors. Hotel and hotel staff were great. Food was considerably below standard of Agile Australia but that could be my expectations on freshness and I do appreciate that all meals were provided with no requirement for me to source food elsewhere.
  • The cost of the conference is quite extreme when coming from Australia, especially when you consider lost contract time and the two day travel time. I have submitted for three years in the hopes to have my ticket and accommodation covered before I finally got accepted. Without these perks I am not sure if I would make the trip. That said, I do believe attending the conference in the US  is something every enterprise agile coach in Australia should do sometime in their life – the experience is definitely worth it.
  • I had for a while thought that with the US crossing the chasm before Australia that the level of knowledge, expertise and experience would be significantly noticeable. The reality was it was very similar. Partly this could be because 40% of participants are new to the conference, but for the most part the problems and potential solutions we are dealing with in Australia is very similar to the US. In some ways it is reassuring that the divide is not so significant.
  • Some of the key themes coming out of the conference include:
    1) lots on scaling. It seemed like every second person had their own scaling method. What I appreciate about this is that the creation of such frameworks and methods suggests we still have problems that need solving so I don’t expect to see this explosion of frameworks slowing down. That said, the attempt to make money through certifications is a concern for me. I am supportive of open source frameworks, but the personal expense of having to be certified in so many methods is ridiculous.
    2) lots on collaborative learning – there are many people other than myself experimenting with different approaches to a few days of training in order to get better outcomes for organisations.
    3) lots on improv – safe, quick games to get learning outcomes of value
    4) lots on leadership and enterprise agility (as you would expect) with quite a few references to Fredrick Laloux’s work on reinventing organisations
  • I liked the longer sessions at the US conference but think the split would be better if it was 60 mins for a talk and 90 mins for an interactive session. I did really enjoy the number of interactive sessions, but on the downside, I went to a few where the learnings coming out of them were inhibited by the low knowledge and capability level of people at the table I was sitting at. I feel if you go to a session with someone who is an expert in that domain it would be worthwhile to actually hear what their solutions are to problem rather than hearing guesses of potential solutions from participants.
  • I was surprised by the number of organisations in the US doing Agile ‘in the dark’. Their committment to growing an Agile organisation was to send it’s people to the conference (which don’t get me wrong, is great), but that is where it stopped. They wouldn’t pay for coaches, nor even pay for training, so basically it is like doing Agile when blind. I’m not saying this won’t work, however I believe that it will take longer and the road will be much bumpier. If they make these choices knowingly then so be it (but I suspect they don’t understand the impact and risk of their decisions).
  • I understand there was a coach open space on the weekend before. I would have preferred a 4 day conference with the fifth day for coach open space.
  • I am not quite sure about the 13 streams in a row format – sessions seemed to be very unbalanced with a handful of people to full. I can appreciate that sizing rooms in advance is tricky if not impossible. I guess it gave enough flexibility to have a few choices in case your first preference was full or didn’t meet what you were looking for. Part of the problem was with sessions being so long it often took quite a  while to see if the session was going where you would hope it would. Maybe my lesson learnt out of this is to do some pre-reading of the presentations beforehand and picking from a shortlist of three based on that.

So if you attended Agile 2015 and feel like I have missed the point or you simply want to comment then feel free to reply in the comments below.

 

The world of Agile training and mentoring is intriguing me at the moment.  This is how most of us have done it in large organisations for a long while –

  • We build in powerpoint or prezi these gorgeous training decks and train up people new to Agile
  • We outsource our training to groups who do the same as the above
  • We build intranets, wikis or documents worth of content on “how to do <insert Agile activity here>”
  • We teach the “Shu” rulebook without constantly re-enforcing the need to progress to “Ha”
  • We have embed games to re-enforce and experience learnings from training sessions
  • We mentor through SODOTO (See One, Do One, Teach One), but often never get to the TO bit

We talk a lot about innovation and radicalizing the business and yet some of the training techniques we still use are from 1990s. How many Scrum Masters open up this content and use it? How many Scrum Masters experiment and adapt how they work? How transparent, engaging and interactive is this content? Playing games and implementing SODOTO is a great start to interactivity and real-time knowledge sharing, but can we do more?

Recently I have had an awesome opportunity at Charter Hall innovate, experiment and enhance the experience of learning differently. Rather than build decks I have spent many hours building an interactive wall to people new to Agile. It is more an experience than a training session. It is one massive wall that flows a conversation about Agile quite naturally before the tour moves further into the working space.

The “basics” tour has the following elements:

  1. The background of Agile
  2. The Agile Values
  3. The Agile Principles
  4. The Agile Process
  5. The Agile Roles
  6. The Portfolio Wall
  7. The Pipeline Activities Wall
  8. One of the Project Walls

The principles behind the learning wall are quite simple:

  • Create a natural flowing experience
  • Introduce concepts with visual drawings to enable better retention
  • Make the process introduction really simple, bare bones, but…
  • Have the ability to drill through into detail without it overloading the audience. This would help when having more detailed role training.
  • Make everything transparent, no content is hidden in a tool
  • Break up content so that as things change it is a simple matter of changing one small picture

Now before I show you the pictures of what I have created I do want to highlight some intended future changes:

  • Extend the values section to include the Scrum values and the company values
  • Make pictures for the Agile Principles
  • Add in Lean Principles
  • Add in an “other section at the tail end”
  • Maybe add in a visual around all the different Agile methods, edgy and support methods
  • In addition to the wall I am also building a series of agenda cards – these are re-usable packs for Scrum Masters and coaches to use for workshops and key Agile activities (eg Iteration Planning, Retrospective, etc). These cards have some spares so that facilitators can adapt away from the standard set of agenda ideas. On the back of the cards are tips of the purpose of agenda activity and how it could be facilitated.
    What does this mean for a new facilitator? Well they have the clear activities they need to do with how to do it without having to open up a tool (which they don’t ever do), but most importantly this is real time – exactly when they need it. It also provides great clarity to everyone else in the room around what is happening and what still needs to happen when it is utilised as a backlog against a simple wall of “To Do”, “Doing” and “Done”.

Anyway, now for the pictures of the Learning Wall (it runs right to left due to the entrance point, but normally I would have preferred a left to right run). Taken from the right:

_DSC2108

 

Taken from the left:

_DSC2098

The Agile Values (some references taken from Rally’s awesome values picture):

_DSC2071

The Agile Principles:

_DSC2074

The Agile Process (note this is naturally a very specific organisational tailoring, I am by no means saying this is the one and only process for Agile). Specifically, this is the bare bones view. The number of iterations is just for an example.

_DSC2079

And now the interactive version (note how the interaction points line up with the number of iterations).

_DSC2076

With a detailed closeup on the iteration portion:

_DSC2077

A high level overview of the Agile Roles. The three key Scrum Roles are here – Scrum Master, Product Owner and the Team. In addition I have added in our organisational specific governance roles which includes a high level organisational wide steering group, a Business Scrum and the PMO. Again I would like to highlight that some changes have been made to normal roles to suit the specific culture and needs of the organisation.

_DSC2081

Detail on the Scrum Master role (interactive side showing):

_DSC2093

Detailed view on the Product Owner role (bare bones side):

_DSC2089

Detailed view on the Product Owner role (interactive side):

_DSC2094

Detailed view on the Team role (bare bones side):

_DSC2087

The Business Scrum role:

_DSC2086

The Steering Group role:

_DSC2090

The PMO role:

_DSC2085

And that is the Agile Learning Wall! Please feel free to comment on any thoughts and suggestions to enhance the route of complete transparency and no tools that I am on.

I would like to thank both Nicki Doble and James Doust from Charter Hall who gave their support for my experimentation and for their willingness to expose to the world what we are doing.

 

Over the years the roles associated with agile transformations has grown and changed. Fifteen years ago the only roles that existed were those that were associated with being within an Agile team – the Product Owner and Scrum Master. agilecoach

The Scrum Master role hasn’t really changed over this time – it has always been clearly in their remit that they are responsible for training, mentoring and coaching the team in Agile and for ensuring the Scrum process is understood and enacted. So how is it that about five years ago the role called ‘Agile Coach’ came about, and more importantly, what does it mean?

In Australia, partly the distinction was made initially not because it meant something different to a Scrum Master, but because a lot of organisations and transformationalists didn’t want to tie themselves solely to Scrum. This meant that a more general sounding name was needed and Agile Coach came about from that. Over time though, in my personal opinion, it has indeed changed to have some differentiation from the Scrum Master role.

The predominant difference I see between the Scrum Master role and the Agile Coach is not the responsibilities but the experience. Because anyone can do a two day CSM and call themselves a ‘Scrum Master’ there has been a gap of a lot of people who know only the very basics and those that know in reality, through practical application and experience what works and what does not. An alternative to look at it is the broad spectrum of Scrum Masters who are in Shu trying to mentor and coach a team without the skills to be able to do it, versus those that are in the tail of Ha, or even starting to hit Ri. What ‘Agile Coach’ gave us was a means to be able to differentiate between someone who had done a two day course and someone who had lived and breathed transforming teams for a few years.

If I was to put some clear differences into bullet points it would look something like this:

Scrum Master

  • Done a 2 day CSM/PSM course
  • Applied Agile to a single team, once or up to a few times
  • Reading the basic Agile books
  • Basic knowledge of values, principles, process, practices and techniques of Scrum, XP and Kanban

Agile Coach

  • Done potentially more certifications (or been mentoring, coaching and training teams for more than five years)
  • Been mentoring, coaching and training teams for more than three years
  • Starting to read most of the key Agile and Lean books
  • Applying knowledge from a variety of methods including scaling methods, lean and systems thinking
  • Uplifting capability of multiple teams through working closely with several Scrum Masters at once
  • Training, coaching, mentoring and advising not just teams but also leaders
  • Tries to resolve complex departmental waste issues

In addition to the two roles above, another one seems to have entered the agile vernacular in the last two years – that of an Enterprise Agile Coach. So lets take a look at my personal opinion of differentiates an Enterprise Coach:

Enterprise Agile Coach

  • Has led an agile transformation or whole divisions at one or more organisations
  • Has had a team of Agile Coaches working with them to undertake the transformation
  • Defines the organisation’s Agile framework and ensures that buy-in exists at all levels to the change
  • Has read most of the key Agile and Lean books, has started reading practices and techniques that are outside the Agile community including modern management, complexity, finance, metrics, behavioural and organisational change.
  • Training, coaching, mentoring and advises not just teams and leaders but high level executive and c-suite managers
  • Tries to resolve complex organisational waste issues including governance, finance and HR.

So in conclusion, for those of you that were confused about the difference in the roles, I hope this helps. If I have missed anything or you feel that according to your views I have mis-representated something than feel free to comment below. The responsibilities and experience levels noted above are purely my opinion and based on what I have seen and experienced around me in Australia and New Zealand.

In product development the definition of Minimal Viable Product (MVP) is

The product with the highest return on investment versus risk

Popularised by Eric Ries it subtly changes to

The smallest thing you can build that lets you quickly make it around the build/measure/learn loop

I must profess I have a few issues the MVP concept.

mad-scientistMy first is the term. The term MVP is all well and good for you version 1.0 of your product, but what exactly is your next cycle through the loop called – is it called a Minimal Viable Product as well? Why do we not refer to the refinement or further iterations of the build, measure, learn (BML) loop as Minimal Viable Increments? Or better yet, BML increments? We know from using Lean Startup that we rarely get the product right first go, so we should have some simple term that talks about getting it closer to right shouldn’t we?

My second issue with MVP as a concept is that people forget that there is a life cycle to products if you do manage to be successful post the Startup phase. Let’s go through the scenario – you build your first MVP, you increment on it through build, measure learn, you begin to realise customer value, customer growth and manage to retain customers, you increase business revenue; in essence, your startup starts to succeed. Then your customers continue to grow. Suddenly your little tiny product is not handling the growth. You need to desperately take what was a tactical solution and industrialise it, strengthen it so that it can handle the next stage of growth. Your minimal tactical product just isn’t cutting it, it simply isn’t viable anymore. At this point in time the increments from a BML perspective need to focus on operational sustainability – how can you build a platform to sustain an acceptable performance? I call these minimal strengthening increments.

My third issue with MVP is that if you are doing it in a non startup environment – ie an intrapreneur in an already existing and flourishing business, is how to deal with reputational risk. In these large corporate organisations you need to worry about compliance to major standards, either in the country or internationally, you may also need to worry about how your existing shareholders feel about a non polished product out in the marketplace. It is for this reason that you could venture down the path of white-labeling the product, ie taking your brand off it and registering it under a smaller shell of the company, but often it means that the MVP becomes not so very minimal as the company is unwilling to incur reputational risk.

My fourth and final issue with MVP is the very difficult balance between MVP and minimal viable experience (MVE). Sure you could put a product out there to begin learning from, but if the content or the experience of the product is not compelling enough then you are going to risk turning away customers and that comes back to reputational risk for large corporations. Some call this a minimal lovable product.

Don’t get me wrong, I love Lean Startup, but in conclusion, if you are applying it into a corporate environment it is not going to be enough to ensure success and many different considerations need to me made. In a large and established organisation consider the minimal viable increment, the minimal viable experience, the minimal riskable product, and the minimal strengthening increments.

Inventory waste. It is one of the eight forms of Lean waste. It is work in progress or finished goods which are not having value added to them.

In software development inventory waste is best represented in the queued activities in between the hand offs from individual to individual. If using a complicated board, you would represent the full flow or value stream for delivering stories. This would normally contain columns such as “Ready for Development” or “Ready for Testing”. A build up of one or two items in these columns isn’t necessarily bad, but when moderate to large queues start to appear it is symptomatic of constraint or flow issue within the team.

In teams doing Kanban well, they are limiting their work in progress across both the active and the queueing columns (ie “In X” and “Ready for Y” columns).

What a Hotspot board does is visually highlight the inventory waste areas of the team’s flow. Rather than structuring flow going across via the headers or columns, it balances the zones of the board so that the inventory waste areas are all in the center part of the board – ie the key focal area of your eye, highlighting the criticality of watching these waste points by backing the zone in red.

HSB1HSB2

There are a few potential downsides to such a board:

1) Swimlanes become difficult to utilise as a visual technique (as flow bounces around the board)

2) Visual fixation on only the hotspot results in the “In X” activities having reduced focus. This could result in high WIP of in flight work being ignored which would definitely not be a good thing.

To overcome this second issue and to align more closely with one of Kanban’s key pricinples, limit work in progress, I extended the idea of the Hotspot board to become the Twister board (yes like the game with spots).

The Twister board re-introduces work in progress limits in three ways – HSB3

  1. In the hotspot zone itself
  2. In the active flow states – visually highlighting the actual kanban availability through the existence of the circles
  3. In the active flow states – visually highlighting the risk of hitting to top threshold of work in progress through colour – green =  all good, orange = getting close, red = upper threshold of work in progress being met

Note: pictures are examples only of flow and work in progress limits. As always, apply this contextually to your work and teams.