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.

Agile and Lean Change Management: Trainer Interview - Jude Horrill

This is an interview with Jude Horrill who is the co-trainer of the Agile and Lean Change course with Peter Lam. The purpose is to give you further insight into the course. We cover a few topics, including how Peter and Jude have adapted the course, what you should be looking to take out of the day and advice in general about adopting new tools in the workplace.

As always, if you have any questions or comments please don't hesitate to reach out to us. My email is Ringo.Thomas@tabar.com.au and I'm always happy to hear from you.

Our calendar for upcoming trainings is available here. Registration is available now.

Elsewhere, I've written about about our journey bringing our Agile and Lean Change Management training course to market. In Part 1 and Part 2 I explain how we saw a demand, and then how we adapted and refined the course. 

The reason for telling this story was both to demonstrate the cycle in action, also to give people interested in the course the opportunity to understand if how it's shaped is suitable for them.

“In this Masterclass we cover the two key principles of lean change which are - ‘you can’t control the way people are going to respond to change, and people are more likely to be engaged if they are involved in designing the change’.”

Ringo: Why did you first get involved in running this course? 

Jude: Over recent years it’s become evident that businesses are challenged by the pace and complexity of change and how to respond.  This is leading to changes in what they offer and how they operate. Alongside this is the need for a different approach to how they make those changes with their people.

I had heard about Jason’s Lean Change practice and decided to do his course.  His 3 step cycle hit the nail on the head in terms of simplifying steps and engaging people in the process.  My business mantra is Connect, Simplify, Change, which is very aligned to Jason’s breakthrough in approach to current challenges.

I am also passionate about new ideas and coaching others to see things differently.  I believe we need to change the world of work, and addressing the change process in businesses is an integral part of that world.

Ringo: What are the changes you’ve made to Jason’s original course content, and why did you choose to make them?

Jude: The biggest shift was to build a one day offering instead of the standard two day workshop.  Our primary target audience of Change Managers are already experienced in the people side of change and have been clear on what they were looking for.

Their desire was to get straight into learning about agile, what good agile looks like, what a lean change approach is, and how and when to use this in their day job. 

So, by focusing content and exercises directly to those needs we were able to build a one day masterclass that enabled a faster step through of information - tools - exercise - and application.

Ringo: What do you hope people are able to take out of the day?

Jude: Because we have been very disciplined around tight content, practical work and application to participants’ current work programs, my hope is that people will be able to use their learning on their return to work.  

A fundamental take out for me is that they start to see through a new lens and to then think independently and confidently about different ways of approaching their change work.  

In large part, change work is about engagement and communication, and if participants gain ideas, insights and shared stories on how to achieve this through the use of a blend of tools then I am very happy.

Ringo: What should people be thinking about on the day to ensure they get the most value?

Jude: I am experienced in the use of a blend of methodologies, tools and engagement techniques in change work, and big on creating tailored solutions to every change situation.

In my opinion, if people who have been given responsibility to deliver change successfully don’t continue to learn and adopt and try new things they will not be relevant in today’s and tomorrow’s marketplace.

If participants have an open mind, or a similar mindset coming into, and during, the Masterclass then they will gain the most value.

Ringo: What would you recommend people do to prepare for the day? How will this assist in the learning?

Jude: Think about their current change program, project or problem in the most succinct way possible.  Get to the core one or two issues and write it down.  Capture what insights you might have as to why these issues exist, what you’ve already done to respond, or what you could do.  Essentially get your thinking cap on and root out the essence of the “why” question.

This will assist on the day as you will come with a heightened desire to solve your problem, will have done the groundwork, and importantly started to think about the solution in terms of the 3 step lean change cycle of Insight - Solution - Experiment.

I also recommend that they read some core material on Jason Little’s website at www.leanchange.org to have a broad knowledge of the process he uses and case study stories from blogs.

Ringo: What’s the biggest piece of advice you’d give to someone trying to bring a new framework or tool into their workplace?

That they need to be confident in having conversations along the lines of ‘different times require different solutions’.  Even if they are not in a position to influence changes I have had personal success and success with coaching clients who have simply changed one thing they personally do.

This has led to change in those around them and then in wider and wider circles.  The old saying, ‘build it and they will come’ actually works.  You can’t change others but you can start by changing something in and for yourself.

Also, start small and don’t think you have to change everything in a wholesale way from the get go.  Blended models work really well.  Lean Change and Agile doesn’t work in every scenario, and it doesn’t have to.  That’s not what the challenge is about in terms of building a new way of working.  In my experience it’s about having an agile mindset.  About ‘being agile’ not just ‘doing agile’.

Ringo: What’s the most common hurdle you see people come across when trying to bring a new framework or tool into a workplace?

Jude: Influence.  The feeling that they are unable to start a new conversation or not empowered due to their role or level of experience or many other factors.  

The other common hurdle is Risk.  Organisations are still very risk averse, and as the outcome of change is inherently unknown, they prefer to avoid it and stick with the status quo.  

One of my favourite sayings is “nothing changes if nothing changes”.  In this Masterclass we cover the two key principles of lean change which are - ‘you can’t control the way people are going to respond to change, and people are more likely to be engaged if they are involved in designing the change’.

So a logical solution to the implementation hurdle is to adopt lean change ideas to engage more people across the business so they feel included and to collectively become more comfortable with trying new things and supporting each other.

This way when the next change comes, which it will,  there are increasing levels of comfort embedded in teams around the experience of change.  

At the end of the day, we’re all in the same boat and lean change is one enabler to smoother waters.

Your MVP is all Bull

By Anton Rossouw.

When I need some inspiration, I often start on the journey searching for it by looking at some of the works of my favourite artists, one being Marc Chagall, another Helen Norton and of course Pablo Picasso (I also love his quotes as they resonate so well with me!).

One of these explorations brought me to think about artistic merit in product design and how we need to think about and approach what we are designing in agile terms known as the MVP (Minimum Viable Product) in collaboration with the product owner.

 I believe at minimum the key characteristics is that the MVP must at least be:

1.    Valuable to the product owner and the end-clients with a real business purpose and utility and not just be another “nice thing”.

2.    Do-able practicable with realistic delivery in line with the team capability in a short timeframe (weeks not months).

3.    Affordably satisfy a tangible ROI in a no frills way and be able to evolve from an initial base  delivery to create more and more incremental value else it should be "extincted" quickly.

With that in mind my teams and product owners often ask how they  should approach the definition of the MVP and in particular "what it should look like".   Well, that's not an easy answer at all because the product concept may only exist initially as an "idea" that needs stimulation for manifestation. 

Before starting the  stimulation process we need to agree that we need to satisfy the above MVP key characteristics, and then enter into activities that will lead to the products exhibiting "artistic merit" by stimulating team creativity and innovation so that we can craft the MVP from virtually nothing into what it is to become.

For this not to just be a "woolly generic statement",  we need to refer to some examples to make it easy for the team to generate inspirational emergent ideas that will lead to "what this would look like" in real life. 

So for this I like to use Pablo Picassos "Bulls"  as  inspiration and illustration, by talking  the image through with the team and the product owners. This particular artwork is a very powerful creative instrument that often amazes with how quickly the teams "gets it" to start talking about what the MVP should look like.  

This image quickly lands the team to distil the product design framework to its most minimal and simple essence, exactly as Picasso does with his bull!  

Although Picasso has followed the process to "de-construct" the bull from the most complex to its mere essence, one can approach it from both sites as either de-compositional or/and re-constitutional points of view.   

Its for me the perfect illustration of how to achieve the ultimate MVP of the Bull. 

To sum up; To land on a great MVP the team needs to process some iterative hard tack inspiration interspersed with interaction and collaboration on de-and re-construction of the product as a Bull!

And now in the spirit of artistic inspiration some whimsical imagery from Helen Norton with "The Bull of Heaven Descending" 

(Note. The bull sculpture in the header is available for the serious collector - buy from here)

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

The invisible gorilla

By Venky Krishnamurthy

Recently I read about  NASA’s Columbia mission disaster. As many of us remember, on Feb. 1, 2003, space shuttle Columbia broke up as it returned to Earth, killing the seven astronauts on board.
 

View fullsize

The Columbia Accident Investigation Board (CAIB) concluded the following in their final investigation report 

“Cultural traits and organizational practices detrimental to safety were allowed to develop,” the board wrote, citing “reliance on past success as a substitute for sound engineering practices” and “organizational barriers that prevented effective communication of critical safety information” among the problems found.
”

As per the report, some of the engineers discussed the dangers of foam falling apart with the senior management. However, the management simply ignored them and didn’t attempt to find a fix, which is a reflection of deep cultural issues at NASA. The management didn’t think this was a major problem. The report also claims that management didn’t bother to take action because of a view that the problem was unfixable, based on past experience.  

The reason I am referencing this article here is because I see a lot of similarities between this case study and the way enterprises typically operate. When the team members see a risk in the project and reports to the management, either the issue is ignored, or the team member is termed as a trouble maker.

From the leadership point of view, the takeaways for us are:

1. Give serious attention to every risk or issue raised by the team members. Don't ignore any even if it sounds stupid
2. Don’t let your past experiences stop you from finding and trying new solutions.

In large enterprises and complex programs, issues crop  up all the time. Leaders could become immune to listening to problems and start focusing only on larger issues. In fact, this pattern of giving too much importance to bigger issues and ignoring the smaller ones seem to cause major disasters in history.

As per the discipline of complexity science, many a times the weak signals carry very powerful and important information. We tend to ignore them and focus only on strong signals, thus causing major problems.

The experiment from psychologists, “The monkey business” illusion is a classic example of how we miss out on the “Gorillas” amidst chasing key goals.

The Columbia disaster could have been averted if the management listened to engineers and attempted some steps to fix the foam issue. 

Similarly, major challenges in the project schedule, scope or budget could be averted if the management listens to the weak signals. That is, small risks hidden from the "big visible charts".

Before I conclude, let me ask you two questions.

Think about your current project, visualize your project risk board"

1. Have you missed seeing any “gorillas”?
2. Have you recently ignored any issue raised by a "junior" team member?

---

KEEPING TABS - TABAR'S NEWSLETTER

If you want links to interesting reading and notifications about upcoming events in the Melbourne and Australian lean/agile/workplace change community, please signup here.

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.

Zappos and the "no bosses" approach

By Venky Krishnamurthy

Zappos CEO, Tony Hsieh

After reading this article from the Washington Post, I felt saddened to see many employees leaving Zappos. Zappos might have a point to prove that these employees are incapable of adjusting to their new “way of working”. 

I think it is dangerous for Zappos to survive in the long run. Here are two reasons:

1. The diversity of thinking:  success of any team, group or an enterprise depends on its encouragement to the diversity of thinking. If everyone in the organization is forced to think in a certain way, one will end up breeding “Yes” masters and thus killing creativity, innovation. 
   
   As one could see, Zappos management is forcing people to work in certain way and non-aligned workers are booted out but in a diplomatic fashion. I agree that the Holacracy way of working can benefit the organization, however Zappos is killing the a foundation that Holacracy promotes; that is, respecting people and their opinions.
   
   As per one of the research, employees perform at their peak potential when their individuality is respected and protected.
   
   Organizations flourish and succeed with inclusive policies rather than exclusive ones. 
    
2. Brain drain: A bigger issue is the impact of brain drain on the organization. There are rumors floating around that many employees who opted to quit Zappos have set up new startups. The three months salary is good enough for many entrepreneurial people to use it as seed funding to setup their own business. Loss of such talented people is a great tragedy for the company.

Sometimes, I also feel that many organizations come up with fancy ideas/strategies as part of laying off people as well.

What do you think about Zappos decision ?

For those of you interested in this topic, the Melbourne Agile and Scrum Meetup group will be discussing Self Organisation and Holacracy at its next Meetup on 27 May 2015.

Keeping Tabs - Tabar's Newsletter

If you want links to interesting reading and notifications about upcoming events in (mainly) Melbourne and Australian community, please signup here.

LeSS is more in Australia

By Anton Rossouw.

It was great to have Bas Vodde in Melbourne from 24 - 26 February 2015 to bring the first Certified LeSS Practitioner course to Australia. Its been several months in the making following a plot with Bas to visit Australia, crafted over great Japanese barbeque and Sake at Clarke Quay in Singapore.  The Melbourne location was also good enticement to exploring  Tasmanian Whisky in pursuit of the most excellent in the world! With that trigger discussion still clear in my memory I started day 1 of the 3 day LeSS training with Bas and 15 others at our partner organisation Elabor8’s training room.

My initial expectation of LeSS was that there could not be that much more to scaling Scrum that we weren’t already intuitively doing in some way, so anything new under the sun? I was very wrong! It dawned quickly that what Bas presented was taking Scrum itself to a whole new level of excellence! What I learned was somewhat of a surprise because “LeSS lets you do better Scrum” too. It’s not only about scaling teams and large product delivery but also at the same time amplifying the practical goodness at the heart of Scrum i.e. the agile stuff that really works. The course also brings many new agile aspects to the fore while also remaining simple, compact and focused. The particularly powerful concepts that resonated deeply with me were:

• Steps and strategies to evolve Agile scaling into the wider organisational context in a low risk productivity enhancing way
• Building cross functional feature teams across the organisation while driving understanding and contribution to the business domain
• Applying organisational, product and process improvement from running retrospectives (overall) at scale emphasising that learning is at the core of LeSS
• Specific roles for management steers them in support of teams and not control of people
• Managing the one product backlog and driving Done and Un-Done work to get to extended enterprise level “totally Done”
• Sincronisation of sprint time boxes into the same calendar cycle
• What do we do when the product requires more than 8 teams i.e. going “Less Huge”
• Two step sprint planning to cover enterprise level and team level planning for delivery
• Managing the backlog according to dynamic requirements areas that reflect the enterprise contexts
• Moving the teams and the organisation structure to customer and whole product focus
• Applying Less principles underpinned by systems thinking that further enhance and support better Scrum
• Moving away from project focus to continuous emergent Inspect and Adapt driven delivery
• Moving from component teams to feature teams using a planned strategy based on a long term adoption map
• Sometimes temporary fake product owners are valuable and needed!
• Using and authority matrix to differentiate responsibilities for product owners, management and teams
• The simplicity at the core of LeSS will de-complicate the organisational structure over the longer term and drive efficiency

In summary LeSS is not only about how to scale Scrum into a transforming organisation but also how to do better Scrum at every level. This emerged strongly from the stories throughout the training informed by Bas’s years of experience and deep thinking on practical application of LeSS.

Indeed a great start to more LeSS being done in Australia! I am convinced that LeSS.works as what happened to the relatively recent and unknown Tasmanian Whisky is also earmarked to become the de-facto reference to Scaling Agile excellence in the world. Go LeSS! 

Bas and Venky

Personal Kanban FTW

It was a lot of fun presenting on Kanban at 1stConf last week, it was a popular session and special thanks to Neil and Martin for helping make it fun. 

In my talk I gave out Personal Kanban boards and I've had a lot of fun using them myself, here is the design, inspired by Sandy at Nomad8. 

View fullsize

I've found myself wanting to cary around the printed kanban with me and I've discovered a relatively easy way:

I rolled up a blank A4 piece of paper and used sticky tape to turn it into a tube for the board to slide into. As a bonus the sticky notes fit in the tube along with sharpie and bluetac. I need plenty of bluetac to flatten out the board after storage.  

Hope you enjoy you Personal Kanban boards!

My first brush with Large-Scale Scrum (LeSS)

Venkatesh Krishnamurthy

I had my first opportunity to practice LeSS in 2006.  While I was with Valtech in Bangalore, Craig Larman, who was, the chief scientist was already in the process of forming LeSS ideas.

Being a Scrum Master at that time, I had the opportunity to work with Craig closely and watch him implement some of the LeSS principles, tech practices and structuring the organization to be nimble. 

Being a computer scientist, I got impressed with the technical practices and started making my hands dirty in integrating various tools, rolling out configuration management practices and setting up continuous delivery/integration and deployment environments. I was able to capture some of these experiences in an article I published in 2006 for Agile Journal. This is accessible here. It was aptly titled, "Tools integration in distributed environment". 

Another pet project that I worked with Craig Larman was building something called "Virtual Lava Lamp". 

View fullsize

Virtual Lava Lamp

As one could see from the screen shot above, the Lava Lamp was integrated with the Continuous integration environment(Cruise Control + SV) and build results used to trigger this lava lamp. Green indicates all good and red used to encourage the developers to fix the build.   Craig and I built this on a simple X386 machine, which was super low cost.  

All the good technical practices are covered as part of  LeSS framework and under the Technical Excellence subsection as shown below: