How to Boost Agile Team Performance with the Power of Touch

/0 Comments/in /by

Most of us are lucky to have five senses, yet we only use sight and hearing for work. What about the others, namely smell, taste and touch?

First, smell. Research tells us that it produces the strongest reaction… we all remember the girlfriend from 20 years ago, when we smell that perfume again, don’t we boys? What about taste? Well, taste is one hell of a reason why eating-out is such a pleasurable experience! Neither though are really applicable to our daily work.

But what about touch?

Indeed, what about touch? It turns out in fact, that it is a very powerful sense that is also very applicable to our daily work as Agilists, especially those that use a physical board.

But the power of a physical board is still vastly under-appreciated so teams often resort to hiding behind electronic tools, even teams that are co-located.

Yet as we will find out, when the full power of touch is utilised together with physical boards, we get a huge boost in the sense of ownership and accountability and thus performance.

To understand this, we need a few short stories, one involving the power of the pen, followed by subtle Apple and finally advice on how to touch your customer.

What About Writing – We Live in a Modern World Afterall?

Last year I was lucky enough to attend the Global Peter Drucker Forum in Vienna. I highly recommend it, the presenters are world class, and include the likes of Clayton Christensen, Roger Martin and Stephen Denning.

Anyway, one of the presenters pointed out that those typing notes were wasting their time. She went on to explain that when we type, we very quickly start to copy, and do so verbatim. Meaning we capture what the person is saying, word-for-word without thinking. Not only that, our brain is also having to think by processing internal thoughts such as “where do I save this, where is the @ symbol, how shall I call the file, I cannot type fast enough” etc etc etc

Yet when we write, our brain is free to think. We can doodle too which is also proven to be a mode in which our thoughts are synthesised.

All of this results in far stronger thought and digestion and thus far greater potential for recall, when we want the information at a later date.

What though, if you are one of those digitally minded people in today’s modern World? Well, you can easily scan your notes after the event and store the images in something like Evernote and guess what? Evernote can perform pattern matching to find words in images. So, no excuses, use your brain for thought, not copying.

If you would like to explore these claims in more detail, here are three articles:

  1. Life-Hacker: “The Benefits of Writing by Hand Versus Typing”
  2. Scientific American: “A Learning Secret: Don’t Take Notes with a Laptop”
  3. The Wall Street Journal: “Can Handwriting Make You Smarter?”

But, what has this got to do with an Agile team’s physical board?

Well, it is simple. Make sure the team members write their own tickets. In doing so they will think more deeply about their ticket and as a consequence, they will have a greater sense of ownership and responsibility, and thus an increased desire to get the task done.

Subtle Apple

A few years ago, when the iPad 2 came out, I ventured into our local Apple store to purchase one. But the blue-polo-shirted “Genius’s” always told me that they’d sold out and did not know when they would be in stock. “Some genius” I sarcastically thought.

After the third time, I got slightly annoyed and walked over to the MacBook Pro laptop section of the store. Put myself in front of the last remaining available alien-looking thing, after all I’d been using PCs since 1986, adjusted the screen so I could at least try it, clicked around a bit and before I knew it, bought the alien beast.

Not only that, I walked out feeling great. No “buyer’s remorse” what-so-ever.

How did this happen? For goodness sake, I originally wanted an iPad!  Was it stupid male-shopping-impulse-buying?

No, I just felt I had to have it.

Something however, was playing with my mind. Something very subtle, but actually done on purpose by those clever people at Apple.

Have you ever noticed that all the screens are set to an angle that makes you adjust the screen?

This is on purpose. Apple want you to adjust it and when you do… guess what… you are touching it and Bingo! That is the moment they have you.

You immediately get to feel the quality and want one. So you ask for one. But it does not stop there. When you get it, they ask if you want help. You say “yes” because you are now flush with adrenaline, success and excitement.

Next, something else rather unexpectedly happens: They ask you to unpack it and open it. They do not touch it. You earned it. You own it. You value it. You possess it. No one else. It is Y-O-U-R-S.

Now this is genius psychology at play and in fact, Apple’s subtle approach to raise the sense of ownership through touch is well documented in the first of these two articles, the second then supports the claim:

So what has this got to do with an Agile team’s physical board?

Well, if the team is writing their own tickets and they themselves place their card / post-it onto the board at the end of Sprint Planning, and they maintain the remaining effort and they move the tickets during the Sprint through to “Done”, then they will have a greater sense of ownership. Because just like that MacBook Pro, that card or post-it belongs to them.

Touching your Customer

Ok, no, we should not necessarily touch our customer. But we should use the power of touch to get our customers engaged!

And customer engagement is one of the most common issues I hear. This is especially true at banks, insurance or pharmaceutical companies or other such large corporate institutions.

In such places, a project will be set up and there will be representatives of “the business” involved in the project.  After a while though, even after highly successful, motivating kick-offs, “the business” stops attending the Sprint Reviews.

This is despite the fact that, at the end of the day, it is their project. They are paying for it!

Amazingly, even when this rational, very logical argument is played back to them, in a last-ditch appeal for engagement, it often “falls on deaf ears”. Why? Because the people that should be engaged on an almost day-to-day basis are not only too busy but also, when we think about it,  it is not really, directly, their money.

I first faced this problem in an Agile team way back in 2010. Back then, we were developing a product for multiple remote customers. During the first sprint reviews, done over telco and screen sharing, we could sense the clients falling asleep. Then, suddenly after the 3rd Sprint, one customer requested:

“Can I try”

We immediately panicked. Every single one of us, deep inside, literally died. We froze with anxiety, pure fear.

But sure, he could try.

It turned out to be a truly amazing turning point for the whole organisation and for all of our customers:  Our developers starting asking questions. He debated with them on details. The other clients got involved and in the end, our clients started to demand the software earlier, compared to the previous two years, where the very same clients never ever wanted our software.

Today, we can express it differently: They started to pull the software through our team. We no longer had to push it onto them.

So what happened?

Yes, you’ve guessed it – the client “touched” the software and in doing so raised his own sense of ownership.

Now this is genius.

In Summary

Use the power of touch whenever you can to raise the sense of ownership and accountability across all members of the team, including customers. Do this by getting:

  • People to write their own Stories and Tasks on Post-It Notes or task cards
  • The team to put their own cards on the physical board
  • The team to update and move their own cards during the Sprint
  • Clients to actual demonstrate the software during a Sprint Review

About the Author

Matthew Caine is a method-independent Agile coach, consultant and trainer. He is also a co-founder of the startup accelerator NineAligned through which the startup “www.AgileStickyNotes.com” was founded.

If you love your physical board and you liked this article, you can get a 20% discount on 3M Super-Sticky purpose Swiss-designed Agile Sticky Notes by clicking on this link.

Matthew lives in Zurich, Switzerland yet loves to go fishing in the remote Northwest coast of Scotland.

Picture credits: nick_thomps / 123RF Stock Photo

The Bungsu Story book

/0 Comments/in /by

I’m writing a book on a very special experience that I was lucky to be part of during my time in Indonesia. In this post, I wanted to give you a little introduction to how the story happened, a short glimpse into what happened and also something about what is going on right now.

The Background

In 2013 my wife and I moved to Indonesia to work for the Salvation Army there. It’s been a life-long dream of my wife to work abroad helping underprivileged people – she made a strong hint about it on our first date (just so that I knew…).

For some years I had a hard time thinking about what my programming skills could be used for in that context, but as time progressed,

I started to be more and more interested in agile methods and how to work effectively together in teams. *That* could be useful I thought – and I was right.


We accepted positions in the Salvation Army Health Foundation in Indonesia which governs six hospitals and 17 clinics spread out in the vast country. Elin, being a nurse, was the nursing consultant helping the foundation to focus on quality in this important profession. My job description was focusing on the strategic plans for the hospitals and helping the directors of the hospitals to develop strategic plans. As it turned out my job was though to do there, in part due to language challenges (very few people speak English), but also because the groundwork for me coming there was laid. Why should the directors of the hospitals listen to some Swedish guy that just dropped in from above? There was no proper answer to that.

However … another need arose.

The Story

One of the Salvation Army hospitals was just about 150 meters from our house. Naturally, we had close relations with both the hospital and the staff there. Both my kids and I had been patients sometimes there.

That particular hospital, Rumah Sakit Bungsu, also had problems that we little by little discovered:

  • They served too few patients. Some days just a couple of patients for a hospital with 55 beds and 120 people employed is simply not financially viable. The **cash flow** problem was apparent. In fact, some months invoices and salaries could not be paid.
  • The **salaries** that we did pay was **below the minimum standard** in the city, which of course is not legal
  • Finally we’ve learned that the hospital was operating on probation since the **operational permit was not valid** since one year back.

On top of this, the building of the hospital was ancient and in bad need of renovation. The roof, in particular, was in need of repair.

When the story starts, I just return from being out of town, finding that the ceiling repair has gone horribly wrong. The roof has practically collapsed onto the second floor and then a week of rain has caused severe damage not only on the second floor, that looked beyond reparable but also on the first floor where water is dripping down.

This story is about how we got out of that horrible situation described above, into being a fully operational, certified, patient-filled, joyful and hypothesis-driven hospital in 1.5 years. The driver behind this change was kanban and many lean/agile practices that I’ve picked up during my career.

I hope that you, as I did, will gain a deeper and better understanding of these principles and tools by seeing them applied in an entirely different setting and context.

The Writing

During my adventures in Indonesia I kept blogging about it. One post in particular caught the interest of Vasco Duarte, and he invited me to write a book about the experiences there.

I was first reluctant thinking that what we had done was nothing to tell really, but as we started to throw topics back and forth, I realized that the story was something that could be helpful for others to read.

We are now in the middle of writing the book. I have written the whole story down, and together with the awesome people of Oikosofy we are now working to make the story crisper and focused since the base material probably holds content for at least two books.

Right now there’s a site where you can get hold of the first chapter and get the subsequent chapters as we finish them. I’d love to get your feedback and first impressions on that.

The Other

I am also giving presentations, telling this story, and you can see one presentation on YouTube from Lean Kanban North America 2016 where I was invited as a speaker and nominee to the Brickell Key Award

During 2016, I will present this topic on the following conferences:

The Summary

The things that happened at RS Bungsu that I was fortunate to take part in transformed me completely. I hope that I can share some of that and that you, as I did, will learn lean/agile principles more in depth. I would be honored for you to join me on my journey.

Please contact me with any questions on @marcusoftnet

 

No Estimates: A Brief Introduction and Practical Uses

/0 Comments/in /by

Estimation has become engrained into our daily lives. How long will it take me to get to work? What should I budget for my grocery spend this month? Literally on a daily basis, we surmise outcomes virtually from thin air. This behavior has infiltrated the workplace and now has become a cornerstone of project planning without which we feel we could never dream to begin our work.

As it relates to project management and software development, clients predictably lead with a few standard inquiries: How long will this take? And how much is this going to cost me? If you’re not familiar with the No Estimates movement, you may feel like, yeah, these are reasonable questions that I should be able to answer with some degree of accuracy.

While we can understand, as humans programmed to think we need estimations to make wise decisions, that a customer would want to know these projections from the get go, humoring this need, in fact, works to the detriment of how we go about managing our projects.

In the 1950’s, the Japanese began a movement focused on Lean principles. They found that keeping an inventory or parts and pieces needed for manufacturing was a poorly designed plan. It can be difficult to grasp at first, but they soon realized that having their materials supplied “just in time” was a more efficient and cost-effective use of their resources. It allowed them to utilize warehouse space for revenue generating activities rather than a store, and it enabled them to cutout unnecessary upfront costs.

No Estimates is another type of Lean system. Deciding which activities are slowing you down or wasting time and money on the front or back end as they relate to estimating practices and eliminating the need for them altogether are at the core of this method.

Why we’ve become addicted to estimating

We’ve quite literally become addicted to the practice of estimating. It provides certain levels of comfort to feel as though you know what to expect. The problem is that estimations are little more than guesses providing us with a false sense of certainty. Having financial projections allows for budgeting but in the case of companies working on software development projects, the return should be the focus, not the investment.

Why estimates don’t work

Estimates simply don’t provide the benefits we’re programmed to believe they do. There are far too many uncontrollable variables in the workplace that prevent 100% smooth project progression. Software development projects require multiple teams with varied skills and skill levels. Not to mention, rarely are we ever working on simply one project at a time. This being said, the act of transitioning a project to the next team is hardly ever a perfect baton hand off.

People take vacations. They take leave for personal reasons, and they take ill. These factors simply cannot be foreseen and can completely blow your estimations out of the water. Not only can setbacks like this push back estimated deadlines but there’s a chance you’d need to bring in outside sources to finish the job hence creating unforeseen uplifts in your estimated budget. So much for estimations.

Estimating comes with other dangers such as living up to those estimations. This can go either way, but keep in mind that once goals are set people adjust their workflow expectations to meet that exact goal. If expectations are set high, you could end up with stellar project outcomes, but you run the risk of falling short. Set estimated goals too low and you’ve sold yourself short.

Don’t forget the most unpredictable factor of all: the human factor. Our estimating abilities are undeniably tied to our personal emotions. For instance, if given a project and told that if you muck up and fail to meet your projections you could risk losing your job, chances are you’ll err on the side of caution and provide conservative estimates. Again, you could be selling the project short instead of saving your job. On the other hand, someone in a sales position could very likely inflate their estimations to give themselves more room to make a buck.

All things considered, we’re coming to see how estimations, while we think we need them, are little more than comforting and restrictions.

How to work with clients without giving estimations

To be clear, No Estimates dictates that we eliminate as much estimation as possible. There are circumstances where estimating will be necessary, but relying on estimations too much is a waste of time and energy and directly conflicts with Lean business practices. This is where forecasting comes into play.

Forecasting and Estimating sound similar. The main difference is that forecasting involves the use of known factors to surmise an outcome. Much different than estimating which is providing simply the best guess. Forecasting can be useful in working with clients that require some upfront “estimations,” but be mindful that past performance doesn’t perfectly predict future outcomes. As we’ve said before, unforeseen factors arise with employees and teams in the project stream.

Managing stories in slices

Your client has provided you some stories at the onset of the project. Tackling each story in its entirety at once may seem like the correct route, but really, it’s not. Breaking down stories into manageable and actionable slices provides you a way to report progress on a more frequent basis. The more frequently progress reports are needed, the more slices you’ll need to make into each story. Discovering which stories are necessary for your project is also important on leaning out your process and reliance on estimations.

An example could be made from a standard IT ticket submission by an employee:

“I need to be able to submit issues to IT so that a particular problem can be fixed which prevents me from working.”

Simple enough, and possibly too small to slice up, right? Wrong. Breaking this request or story down into several slices helps determine the amount of work required to fix it. Picking apart this particular story, we can decode the request into two actionable items:

  • Employee needs to be able to contact IT
  • IT needs visibility into a queue of issues waiting to be worked on

We’ve successfully limited the scope of our solution by identifying two features to focus on that will inevitably solve the issue. Slicing stories into multiple actionable parts helps us to actively manage projects.

Slicing up stories also helps with time management, a piece which helps to eliminate estimations. Breaking up stories into chunks helps to separate quick tasks to those which more time-intensive. This particular form of “chunking” enables your team to implement temporary solutions in a live environment, therefore, mitigating risk. It may be a few more steps, but overall it helps with operational implementation.

Some stories need to remain intact. Such stories should be given a maximum calendar duration a couple of months, of course, depending on the overall size of the project. Anything broken out of these should be given a maximum duration of a day. Any user-specific story should not be granted any level of advanced priority beyond a one-week timeframe.

Breaking stories out based on this practice enables you to determine how many of each category can be completed in a given time frame and provides accurate forecasting capabilities.

Track historical data from the start

Providing progress updates is essential in keeping clients who have not embraced the No Estimates theory happy and secure in your ability to complete the project according to their expectations. If data is not collected from the onset of a project, it can be difficult to piece together a before scenario due to changes in technology or staff.

For example, keeping track of your story deliverables (in slices, remember!?) can allow you to extrapolate how many RTSs you’ll be able to produce over the life of the project. This type of forecasting (not estimating) can be valuable to your relationship with the customer and goes far in demonstrating project progression.

Making the transition to No Estimates

Changing our way of thinking and the manner in which we do things is difficult no matter the task. So, we should expect nothing less from the implementation of a new project management process. Baring this in mind, cutting out estimates on day one of the transition is not realistic nor is it expected. There are, however, several things you can do to pave the way to a lean, No Estimates, project management practice.

Create story points

Basing your projections on story points rather than days and monetary costs is the first step in the No Estimates change. The benefits of story points are important and much more helpful than providing nothing more than a generic timeline. Story points help you to discover dependencies and complexity of issues. Story based estimation allows you to break a project up into predictable milestones.

Eliminate estimating task timelines

Trying to gather data points on story progression is counterproductive especially when compared to the overall time estimate to completion. Often we’ll see a story broken down into sub-stories with estimated timelines only to find that when they’re added back together, they don’t meet with initial expectations. Anecdotal progress updates are more useful to your overall completion goals.

Limit time to complete stories

Any story that starts at the beginning of one iteration that isn’t completed by the end of it points out a failing in your organizational structure. By limiting the time stories are allowed to be floating out there without resolution helps to point out these shortfalls and further your No Estimates program development.

Tracking

As mentioned before, keep track of the time it takes to complete different types of stories. This type of information can become invaluable for future project forecasting.

Realizing when you’re late and what to do

Just because we’re aiming to rid ourselves of estimated time restrictions doesn’t mean that we’ve exempted ourselves from being off schedule or coming in late. One of the primary reasons for delivering a project behind schedule is because the scope was unrealistic, and the only way to remedy the situation is to have a serious talk with your client about reducing the scope of the project.

No one ever wants to admit that they’re not able to finish exactly what they’d set out to do, but it’s important to understand that if you followed the No Estimates theory and worked on the most important elements of the project first, it is likely that the client would be able to do away with certain items in order to get the project wrapped up. Maintaining flexibility and organizing the project so that it’s simple to see that each component or story may not necessarily be reliant on the next helps one to recognize that it is possible to deliver on some but not all of the original story requests.

It is quite common for the scope of a project to grow while it is still ongoing. If you’re worried about the scope being inflexible, the mere fact that additions can be made on the fly will tell you that it surely is not. Adjusting down as you go is a stellar way to keep a handle on the overall scope of the project. As you begin to understand the stories provided and begin to weave the solution, you’ll find that some of the stories don’t need resolution after all.

In the end…

We’re addicted to estimating. Estimating is difficult to get away from and hard to make people understand why it’s not only useless but also detrimental to our success in accurately setting expectations and creating optimal workflow efficiencies. So, what do you do? Changing the way an organization thinks is a mountain to climb and realistically can be impossible. That’s the truth. But, there’s nothing stopping you from implementing No Estimates practices within your team. Demonstrating the benefits of change is much easier than asking someone to quit cold turkey. Incrementally implement the No Estimates methods into your project management style and see for yourself just how superior they are to traditional estimation systems.

If you are interested in learning more about #NoEstimates you can buy the book NoEstimates, just click here.

Living Eulogy – Agile Retrospectives

/0 Comments/in , /by

by Jessica Long

Agile Retrospective Activity

The most unfortunate thing about a traditional eulogy is that the subject of gratitude isn’t around to hear it. An agile sprint is a lot like life overall in the sense that it’s over before you know it. Don’t wait for a moment to become a memory. Capture it. The Living Eulogy Retrospective is one of the more uplifting and unforgettable exercises that I have had the pleasure of driving. If there were ever a way to humanize a team’s DNA and build upon a bond, this is a surefire way to do it.

What you can expect to get out of this exercise

Focus will be diverted away from the traditional accounting side and reflection of the iteration. Concentrating on the people instead of the process humanizes an otherwise methodical system oriented examination. This will result in improved team harmony and synchronization. The exercise is beneficial for both maturing teams and groups that may be struggling with internal team level conflict.

How to do it

Hand each teammate a sheet of a paper as you introduce the exercise. Instruct each person to put pen to paper and identify who they are and what team they represent on the top of the page. For example, “Jess Long is a teammate for the Ginger Snaps.” Explain that upon your mark, each person should hand their paper to the left. The receiver will have 2 minutes to write an expression of gratitude or describe a positive team contribution that praises the subject at an individual level. This can be a single sentence or a short paragraph. Upon hearing the buzzer at the 2 minute interval, the teammate should hand the paper to the person on their left. This action will repeat itself until the papers make their way back to their original subject.

When you receive the sheet belonging to the person to your right, this will indicate that you’ve reached the final round. Urge the final writers to hand the papers back to their owners face down upon hearing the buzzer. Once everyone has received their original sheet, it’s time to ask for a volunteer to read his or her living eulogy to the group. Most participants are eager to see the mysterious sheet that lies before them but if there’s hesitation, you can opt to go first. This is the fun part. As the paper is flipped and the summaries are read out loud, there can be a lot of laughter around subpar penmanship and sometimes even tears of endearment.

Once everyone has had a chance to read, thank the group for extending themselves in such a personal manner. Reflect on the experience and express that you hope each person values their living eulogy as much as you value your own. Urge your teammates to hang these up or keep them in a place they can easily access. Chances are, that is already the intent of your team before you even suggest it.

About Jess

Jess Long has driven multiple Agile Transformations within several large financial institutions. Her love of coaching has enabled her to be a servant leader to many teams and provide individual direction to each of the specific roles that make up a successful Agile alliance. While she values each ceremony that goes along with an iteration, she embraces the sprint retrospective most of all.

If you have questions related to this article, please feel free to contact Jess on Twitter @ScrumAndGinger or through Scrumandginger.com

Picture credits go to: Improve It.

________________________________________________________________________________________

In case you are interested in Agile Retrospectives OIKOSOFY has prepared 10 Days FREE AGILE RETROSPECTIVES PROGRAM for you. This is a complete self-study program where you will learn anything that you need to become a great Agile Retrospectives facilitator.

If you are interested in sharing your Agile Retrospective exercise with us on the format of Guest Blogging please contact us: info@oikosofy.com.