How I used the Lean Change Cycle to help launch and refine our training course (on Lean Change) Part 1

by Ringo Thomas

Ringo Thomas

"Practice what you preach", "eat your own dog food", "be the change you wish to see". We’re all good at giving advice, but how often do we really follow our own lead by doing things at the standard we set while coaching others?

Over the past 4 months we’ve taken our “Agile and Lean Change Management Masterclass” to market here in Melbourne and Sydney.

This is Part 1 of a 3 Part series to share how we used the Lean Change Cycle to take the Agile and Lean Change training course to market. Across the series I’ll be setting the scene of why we decided to launch it, how we gathered insights, selected options and ran experiments to refine the offering based upon what people told us that they wanted.

The Lean Change Cycle

For those of you unfamiliar with Lean Change, it’s a simple 3 step cycle.

                        Lean Change Cycle

• You use lightweight tools to gather insights from your business, team or customers.

• You use these insights to select and prioritise options you choose to address these problems.

• You create experiments that help you test your hypotheses.

• You gather further insights from these experiments that helps you decide what to do next.

I’ve bolded the words insights, options and experiments to demonstrate the cyclic and continuous nature of the Lean Change Cycle, much like Agile.

Everything began with a set of insights we’d gathered that helped us see the gap in the market.

These were:

• The world of work is changing rapidly, organisations need to be able to respond to change both internal and external at a rate not seen before.

• Project Management and Software Delivery has evolved through Agile, now following an iterative, feedback driven approach to delivery as a whole.

• Change Management is beginning to adapt and we believe there is a better way.

We considered our options based on this, and our coaches Peter Lam and Jude Horrill decided to join forces. Peter’s role as a Head of projects sees him applying Agile practices to his PMO’s, Projects and Teams. Jude’s experience has delivered change in Global Operations and Enterprise Transformations for Multi National Corporation’s.

Jude and Peter felt that Jason Little’s Lean Change Management framework is a useful way of addressing these issues. They believed that together their combination of experience and expertise could coach people in a way that addressed the challenges people were facing.

What did we do?

Our first hypothesis was simple -“we believe that if we run a one day training course on Agile and Lean Change Management, people will come”. We challenged the current market offering of a 2 day course with a one day course we felt addressed everything, and we launched it. This was our first experiment. Success was people attending from the kick-off.

People did. Right off the bat our hypothesis was proved true by a very active market demand and people purchasing. By conducting our first experiment we’d gathered information for a fresh set of insights and we were now considering our next options.

So what was next? Where could we improve? We’d had a theory and tested it in the market and now knew this was something to pursue.

We decided two things:

• “We believe there is a market for more regular Agile and Lean Change Management training.”

• “We believe that by identifying and speaking with our customers to understand their problem statements, we’re able to create a course that better suits their needs, messaging that speaks to their requirements and build a community that we engage with.”

We launched three further training courses - two in Melbourne and one in Sydney to continue our experiment on market demand. Success looked like paying participants and customer feedback that indicated we were addressing their needs. Concurrently, I segmented the customers (more to come on this in part 2) and began speaking with them to gather the insights required to truly understand their needs.

To summarise this first phase, it was about testing the market softly to validate our assumptions on a requirement. We did this in a way that set us up to speak with the people we were trying to help and begin to be seen as leading thinkers and coaches in the space.

In my next blog I’ll share the results and insights we gathered by speaking with customers to understand their problem statements and needs, also update you on how the following 3 courses went and our plans for 2017.

If you're interested to hear anymore about our journey email me on Ringo.Thomas@tabar.com.au

---

Find out more about the Agile and Lean Change Masterclass, including scheduled courses in Melbourne and Sydney.

Wet Scrum

Guest post

Many thanks to Gurpreet Singh for allowing us to re-post this article about what he calls "Wet Scrum". He will be in Australia in mid-September as a session leader at LAST Conference.

Wet Scrum

By Gurpreet Singh

Many companies tag themselves "Agile." Agile is the latest Methodology to execute software development projects. Agile has a variety: like Scrum, eXtreme Programming (XP), Rational Unified Process (RUP), etc. Scrum is the most commonly followed these days. Generally, organizations use a blended version to suit their needs, which are confined within their environmental constraints (EEF/OPA, or enterprise environmental factors/organizational process assets).

So, why are companies moving to Agile?

Let's recap the Agile Manifesto to answer this question:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Agile empowers the client with the flexibility to change, as the entire process is iterative and the client is kept in the loop with each sprint's progress. Also, the team plans and commits for work for each sprint and works together to complete the commitment.

This way, it is a win-win scenario for each side:

• The client is updated in real time about the status of the project/product, and the client has the freedom to change the requirements.
• The team is like a small military Alpha unit (five to nine members) working in short progressions (sprints).

The hard truth

Hmm . . . this was the theory. Life, though, is not about black and white; there are grey areas everywhere.

It is easier to "do Agile" than to "be Agile." Agile demands a certain discipline to get the right results.

• Do you timebox your meetings?
• Are you a silent listener during the meetings?
• Is the product owner or ScrumMaster the only person who talks?
• Is the PO/SM "pushing" the work to you?
• Does your PO commit during the sprint planning without seeking team input?
• Are you forced to give XYZ points to ABC story?
• Are you not "open" in the retrospectives for fear that what you say will backfire?
• Are you forced to take on new stories during the sprint that will negatively affect the already committed deliverables?
• Do you never discuss blockers in the daily Scrum meeting, despite the fact they exist?
• Do you expect/wish that the PO/SM would micromanage so you only have to "work"?
• Do you believe the carrot-and-stick method of management is essential?

These scenarios are just few highlights; the possible list is endless. They show that you are "doing Agile" (for the sake of doing it), but you are not "being Agile," as you don't know the real importance of Agile practices and deliverables.

You may be an Agile puppet run by someone else following Waterfall. This kind of Scrum is notoriously known as "Water-Scrum-Fall."

I would like to coin a new term for this method: "Wet Scrum."

Scrum gets "wet" by following the practices of Waterfall. People use Scrum selectively, depending upon context and ease. However, it is very difficult (nearly impossible) to achieve the spirit of Agile by doing this.

How Wet Scrum Works!

Clients need the following:

• More human touch
• Manageable work organized in short sprints rather than trying to manage the entire project/product as one entity
• Real-time updates about work completed
• The power to change the requirements
• High-quality results

These deliverables are produced by Scrum, in theory. However, no way of working can ensure the success of a project or product unless the team is disciplined and focused on making it a success. (We will discuss this point further at a later stage.)

Clients are fascinated about using Scrum to address the needs listed above. This creates pressure on the senior management of XYZ Company to shift to Scrum. And this creates a cascading pressure on middle management, junior management, and finally on our teams to be Agile. The team doesn't necessarily have an awareness of the Agile values, but they need to be Agile, as this is a clear mandate of senior management and the voice of the client. They start holding daily Scrum, sprint planning, and retrospective meetings without a clear vision of the end goals or their purpose. The burn-downs literally burn down these Wet Scrum teams. Sizing seems alien to them. They aren't sure about the roles of the product owner and the ScrumMaster. They believe they are self-organized, but they need some manager to manage their work.

In a nutshell, they are "Agile" as being demanded by the client (or management); however, they are miles away from being Agile. This is a sad state and is cruel for the team. Gradually, the team will feel that the meetings are senseless. For example, if they are regularly taking on more stories during the sprints, the sprint planning meetings lose their purpose and become a waste of time. Similarly, if the daily stand-ups last for 30 minutes, this is a clear waste of the time for the entire team (30 minutes times X number of team members daily).

In the long run, the team will start burning out. They will lose focus and motivation, and the product will fall from creative mode to survival mode.

And . . . everybody will blame Agile (read: Scrum) for this failure. However, if the people involved do not want to make the product/project a successful one, it will be a sure failure no matter which method you use.

Closing note

Competition is high, so companies try everything to make new customers and to sustain the old ones as long as possible. This includes shifting to newer formats such as Scrum, Kanban, etc. However, this kills the creativity, innovation, vision, human spirit, and motivation of the people who actually create the product or execute the project.

Agile was born to empower people and their communication, and this is lost in Wet Scrum.

Wake up now! - See more at: https://www.scrumalliance.org/community/articles/2013/december/wet-scrum

Who comes to LAST Conference?

By Ed Wong

A version of this post first appeared on Ed Wong's personal blog. LAST Conference is part of Tabar's event series, that also include 1st Conf for new agilists and Spark the Change (formerly Dare Festival)

---

I run an event with Craig Brown called LAST Conference. It's happening for the 4th time on 18 September 2015. In 2014, I was pleasantly surprised that the Software Development Today blog rated us #20 in the Top 50 agile conferences.

It's a meetup on steroids

Of the various descriptions there are about the event, I like "It's a meetup on steroids", the best. It's designed for people who have a bit of experience with agile (I run an event called 1st Conf for people who have less experience). We have a whole day of workshops, talks, lightning talks, retrospectives etc. We deliberately have up to 7 concurrent sessions, to keep things exciting and we keep it really affordable, too.

Who comes?

In the lead up to this year's event, I was doing some analysis of who comes along so I thought I'd share. Look ma, I did a pie chart! Click the preview above for a larger version.

Not unsurprisingly, people who fit into a manager role, make up the greatest proportion of participants, followed closely by Business Analysts. The types of job title that made it into the Manager bucket were "Business Solutions Manager" or "Practice Manager".

It's good to see that there is a reasonably diverse spread of roles and it's really good to see that Developers are about one fifth of the cohort, there's a few Architects and a good few QA people. I would like more UX folk to come along…we've got a couple of UX sessions in the pipeline this year.

18 September 2015

We've run the event in the darkest days of Melbourne Winter, up until now. This year, we're going to be in Spring! In order to make use of Swinburne Uni's brand-new Advanced Manufacturing Design Centre (AMDC), we have moved away from their crowded winter term and instead will be on 18 September 2015. We will be opening registration in the coming days (signup to the mailing list to be the first to know), and you can still submit a session idea, over on the LAST Conference website.

Headline sponsors - elabor8

Sponsorship from companies keeps the event affordable. elabor8 have returned as headline sponsors this year. If you'd like to join them, then please get in touch.

What is common between Agile and FengShui ?

By Venkatesh Krishnamurthy

I know this is a tricky question if someone asks "What is common between Agile and Fengshui?" .  Not an easy answer ah?   

Let me give out the answer, both Agile and Fengshui has a lot of believers and followers. The followers have such a tremendous blind faith that they don't question and follow the rituals to the last letter. 

For example, I have seen Feng Shui followers setting up Aquariums, buying gold fishes, lighting scented candles to attract wealth/abundance. Whether it works, don't know.

I am seeing the same trend in Agile followers as well. If there are challenges in software delivery, stakeholders are asking the teams to just "practice" Agile and many a times some popular models like Spotify, SAFe or DAD.  

Many a times, just ignoring all the noise and just applying some common sense could solve many challenges.  

Are you a follower  surrounded with too much of noise?  Do you think ignoring this noise helps in your context?

Mediocre Managers Manifesto

By Anton Rossouw.

I have had the privilege over the past 30 years or so to work with many humane, inspiring and energising managers and leaders.

Since studying Industrial and Organisational Psychology and Computer Science in the early 80's back at university it has always been my hope that management science (with some technology) will foster the development of better managers. However of late I have not seen much evidence of that.

So in homage to the great leaders that inspired me I decided to create an “anti-” view that can be used to tacitly amplify what “good” leadership looks like as the mirror image i.e. “bad”. As a pattern I used the Manifesto for Agile Software Development (representing those on the good side).

Reflecting on my past career I must also confess that at times I caught (like a bad cold) some traits from the not-so-great managers I worked with because it seemed a good idea at the time and the accepted “way we do things here”. I now recognise that one should never take on bad behaviours but stand firm and be brave enough to change it, even though it means you may lose your job (yep its not as easy as that especially when its about money).

After all is said and done to get the “job done”, I always hope that I leave my workspace as happier places where I helped my teams in some way develop and grow to their potential.

Now for the Mediocre Managers Manifesto for creating Mayhem and leading the organisation up Schitt Creek without a paddle:

We are uncovering strident ways to work by doing it and forcing others to do it. Through these ways we have come to value:

Command-and-control over agility and self-organisation.

Passive aggressive conflict over collaboration.

Arguing the details over working the big picture.

Being promoted over delivering value.

Blunt answers over thinking what’s best.

Information secrecy over transparency.

Talking incessantly over listening intently.

That is, while there is most value in the items on the left, there is little value on the right but we will say we do it even though we don’t.

We follow these principles:

• Me, myself and I as the supreme manager always know best.
• Always blindly follow the bosses’ orders because they know best.
• People are annoying but considered as resources to be consumed and discarded.
• Get the job done at any cost but remain true to yourself by using manipulation, throwing tantrums, and whinging.
• Playing people off against each other is an important and fun game.
• Bantering in a critically logical way will be used to belittle, confuse and disorientate the team, and when that fails because they have better answers, then emotional blackmail must be applied.
• When I don't understand something then it is their fault.
• Vendors and suppliers are important because they are someone to blame when my team stuffs up and I don't want to lose many of my team members in one go.
• With power comes responsibility to weed out clever, considerate and open people. They have no place in this world and must be taught a lesson.
• Apathy must be applied to protect us from commitment.
• We believe in our own rhetoric as enforceable doctrine for everyone else to obey.
• Knowingly withholding acknowledgment and approval motivates people to try harder next time.
• Managers are not paid to foster happiness at work, rather spend their time growing empires and attacking others empires.
• My smartphone is at any one time more interesting than what anyone is trying to say in any meeting, except if it is a bosses meeting.
• In particular don't trust individual workers but specifically not teams because they may over time wield more influence than the manager. Facilitate infighting within teams to reduce their effectiveness.  

The Mediocre Managers Manifesto can be used as an assessment checklist tool for managers “where the shoe fits”. If only a couple items apply then there is hope and behaviours can easily be ameliorated, but if most items apply then major therapy and years of coaching would be required to become a “normal” manager again.

To further explore the "bad" side of management one of the best books about it is by Barbara Kellerman. Believe that good management is possible. Inside every bad manager maybe there is a great leader trying to get out!