Archive for the ‘Continuous improvement’ Category

Is Brainstorming the be all and end of all New Ideas?

Sunday, May 23rd, 2010

Author: Robert McDonald

In my experience, there are times when powerful members of a group can lead the discussion and it can promote conformist thinking amongst the rest. The mindset changes from, “what can I bring in the way of ideas” to “how can I best influence or work with what has been proposed”. Don’t get me wrong, I think that brainstorming is very valuable and is here to stay, but there seems to be two important steps which will help it achieve its results.

Brainstorming is not in itself the answer to everything, and taking the top 5 ideas which people vote on can mean less well communicated ideas with merit may be sidelined or ignored. Also if the brainstorming group can be made aware of this issue and work away from conformity and dominating themes to encompass as many ideas as they can.

Recent research seems to indicate this:

http://behavioralhealthcentral.com/index.php/20100330218207/Clinical-News/brainstorming-and-creativity-do-not-go-hand-in-hand.html

They also indicate that if the group feels they have fixated on a certain solution or idea then taking a break can improve the results from the session. This is an excellent idea which I think has real value.

“Business value as a raison d’être? Or is decibel based prioritisation the answer ..?”

Friday, March 12th, 2010

Author: Dean Coulter

I wanted to just put down a few points from my experience about what I believe it really means to provide value to our business in an Agile world.

Agileforthebusiness

  1. Agility has value for the whole supply chain, not just the IT folk! But how well do business operational general managers understand the benefits of agility? IT as collaborators with their internal business colleagues should be able to answer the question – “What does Agile mean for my client’s line of business, their bottom line, their ongoing success in getting their product/service out quicker and more effectively?”
  2. To me, the very core of what Agile means for business people is around the question – “WHERE IS THE VALUE?” This fundamental query guides prioritisation. If there is a demonstrable, quantifiable business benefit, then it’s a candidate for prioritisation. If not, move on, or come back when you’ve got one. This is the key to managing the eternal imbalance between IT service demand and supply. “In the kingdom of infinite demand, she who can prioritise is Queen.”
  3. The value focus leads to the next building block – don’t waste energy building stuff that doesn’t have a quantifiable business benefit. This may seem kind of obvious but “decibel based prioritisation” (wherein the loudest voice gets to set the top priority) is not quite dead yet!

In summary, setting agreed priorities + business value = good Agility.

The Tribe has spoken …It’s (fr)agile…

Monday, February 22nd, 2010

Author: André Harvey

Extending to Susan’s recent post, “Agile is not the holy grail!”, I’d like to add to the provocation by suggesting that ‘change’ is the Holy Grail and momentum is key; and critical to unlocking the benefit and to mitigating the fragility of a change movement is to know the Whys and What Fors.

For those who are personally, or though their organisation, embarking on an Agile methodology change movement – be it adoption, re-acquaintance or the velvet glove of a performance push ask yourself a couple of questions:

  • Do you understand why you use Agile and what the benefits of Agile are?
  • Could you explain it to your mum?

These are important questions. If you don’t get it, how will you become a catalyst for change? An Agile advocate? Change movements are fragile and need your help.

frag•ile
adj.

  1. Easily broken, damaged, or destroyed; frail.
  2. Lacking physical or emotional strength; delicate.
  3. Lacking substance; tenuous or flimsy: a fragile claim to fame.

Teale Shapcott gets it – for her it’s about usability. No point in building the world’s best ‘thing-a-mijig’ if it’s horrible to use. If your staff and colleagues don’t like using it, what type of customer experience do you think will transpire?

Real world example of the above:

I recently opened an account for my daughter at one of the major banks. A seemingly simple request – I thought. It took 2 hours! The entire time all I heard was how poor the system (read: technology) is and how the users experience is worse – no mention of the customer! Perfect example of an implementation performed in isolation of its users and with little OR no thought for its end-customers.

This is where Agile kills its competition – iterations, prototypes, tangible and timely improvements. To market faster with expectations met and the value of the customer experience in top of mind. Even my mum understands the commercial significance of beating competitors to market.

Mark Palmer also gets it – Based on his post - Agile as a Fundraising Tool about workshop facilitation outside the software development environment. It’s a way of thinking and acting. Anyone who can get ~40 people to work through, short-list and agree on 5 key ideas in an hour is worth his weight in gold (Gold bugs take note – resources will boom!). The fact that he’s taken an Agile concept and broadened its application to rugby in a non-corporate setting is advocacy beyond expectation. It takes courage to suggest and commitment to follow through. NOTE: The Agile Academy should sign this man up for a coaching role!

Seek out those that don’t understand…and then listen, Don’t preach.

Humans have been blessed with a physical design that all but encourages you to listen first, then speak: two ears and one mouth. The least we could do is use our human design in its correct ratio.

In my experience there will undoubtedly be and will always remain some resistance to change. This is a good thing. Creative tension so to speak. It keeps us on our toes. Makes us hone our stories.

A constant reminder of change’s fragility. Seek out the resistance. Understand why it is is isn’t happening. As Susan’s post indicated – it might be justified.

This is where Fiona’s earlier blog post on Leadership is magic, whilst not strictly Agile related, which is refreshing, it’s a nice pointer for when you get stuck with a problem or face an explanation that needs more weight behind it – seek to understand first, then find help.

A behavioural science interjection – in a recent McKinsey article, a case study was performed on interactions with customers via call centres. Whereby, if the call had a bad news element the operator would bring it [bad news] forward to the beginning of the call. In doing so, the operator was then able to coach the customer through the news, in turn giving the customer a sense of control of the outcome and improving customer satisfaction.

What I’m suggesting is something very similar for our colleagues that don’t understand the subtleties of Agile or any change movement for that matter.

  • Seek them out.
  • Then coach, don’t preach.
  • Give back control but take the lead.
  • Give your advocacy stories purpose and meaning – make it an fragile claim to fame.
  • Ps. Final Food for thought – Imagine Pixar without story boards.

Agile is not the Holy Grail!

Monday, February 15th, 2010

Author: Susan Davis

I recently attended an Agile training course – Taste of Agile (or as I call it Agile 101), which is an introductory course as the name implies, with the Agile Academy. The first thing that came out of someone’s mouth was “It won’t work in my company. We have special problems, special circumstances, special managers!” The main point of the session, and one that was continually repeated by the trainer, was that Agile is NOT in fact the panacea to everyone’s project or business problems. The trainer actually acknowledged that Agile is not right in all circumstances and sometimes it is just not right for a project, so don’t do it. Perhaps Waterfall is better in that particular instance. It was so nice to actually hear someone acknowledge that working Agile does not mean perfection which is what I think some people think.

Around this same time, I also read a fantastic blog titled It Won’t Work Here by the Agile Executive which gave me even more perspectives to consider. They offered 5 common arguments put forward by people for not going Agile. Forgive my paraphrasing, I just hope I get the basic meaning of them right. They are -

  • Uniqueness (of course the type of company where Agile works, is the only one of it’s kind in the world!);
  • the Secret sauce needed for Agile to be successful. (My company 1 ingredient short of KFC’s secret recipe so what’s the point?);
  • Cultural Change. (It wouild mean such a big change in our thinking and our people just aren’t up to it);
  • Affordability. (Agile costs and we can’t afford it); and finally,
  • Software is not core to us. (Why are you trying to push technology down our throats when we’re not technical!)

and the brilliant thing about the article is that it counters every one of these beliefs. I highly recommend that the non-Agile believers read it and you might be surprised by what it gets you considering.

Why can’t YOU be the Agile advocate at your workplace and use your passion to change? Any change, whether big or small, starts with 1 person asking Why Not?

Embracing change in iterations – does length matter?

Friday, January 15th, 2010

Author: Peter Mison

I’ve seen and been a part of a number of Agile projects now and I’ve seen many slightly different approaches and this is OK because Agile allows the team to recognise through a retrospective what we could do better. So we embrace change to continually improve the way we do things.

Recently I witnessed a change to the length of an iteration in one of our projects. Traditionally these projects have been running using a 4 week iteration cycle – coaches I can hear your already “4 weeks is just too long for an iteration”.

A 4 week iteration tends to feel somewhat relaxed at the beginning and frantic at the end (typically with team members having to work longer hours near the end). You will see this visually in the burndown chart where the tracking of progress tends to drift above and away from the target line throughout the iteration until near the end when all of a sudden the line tracks steeply back towards the target and hopefully lines up when the iteration completes.

In this case, the project team had many reservations about switching to a 2 week iteration from 4, having delivered this way for so long – the motivation to do so certainly did not come from within. Under heavy encouragement from the Agile coach the project gave 2 week iterations a go and the results have been positive and the project have now fully adopted this approach.

What did we see? Well, for starters the team was focused from the start through to the end of the iteration with a nice consistent burndown that tracked very well against the target line all the way through – it’s all about a consistent pace. One of the reservations that the team had before the change was that quality would go down with an increased number of defects. As it turns out the defect rate is very similar to the defect rate over a 4 week iteration.

With Agile, every team needs to work out what works best for them, be it through experimentation, coaching and external influence, BUT it is so important to recognise continuous improvement and to embrace change.

Who said a CFO can’t be Agile!

Friday, January 8th, 2010

Author: Byron Costas

I work in a Chief Financial Office (CFO) as an analyst within a technology services business unit, where Agile has been adopted as the principal project management methodology. Our CFO made the conscious decision that we as a division should also adopt Agile principles in order for us to better understand our internal clients and their business.

  • We have real-time portable big visual charts depicting our complete program of work; i.e. pieces of work from Concept through to the Deliver/Deploy stage;
  • We have daily stand-ups, which have proven to be invaluable in meeting reporting deadlines;
  • We do retrospectives for major pieces of work;
  • We have embraced other Agile and Lean techniques such as MoSCoW;
  • We have actively undertaken Agile training with the Agile Academy (I’ve already completed 4 courses myself and aim to do more); and
  • We have great leadership support.

The biggest realisation for me was that Agile is more about the people rather than strictly a project management methodology and its fundamental principles are equally applicable to technical or non-technical environments. I’ve seen firsthand what using Agile tools and techniques can do i.e. make a great team become an even higher performing one.

We are all aware of what’s happening around us; who is responsible and accountable for a piece of work; and assist each other wherever possible. This has resulted in mutual and trust; fostering an environment of honesty and transparency.

It has not all gone smoothly of course but with mutual recognition and belief in the success that Agile brings, a momentum for positive change and value-add has continued to build. This working philosophy has also extended to the creation of a Passion Board, connecting team members with similar interests fuelling tribes of passion!

Much to our surprise, we even have people from other areas of the business come and check out our various story walls.

Opening up an Agile window to let opportunity fly in – co-locating SMEs

Wednesday, January 6th, 2010

Author: Cara Talbot

In my organisational experience to date the level of Subject Matter Expert (SME)’s co-location and engagement has strengthened from project to project. Thinking of how things were only a few years ago compared to our current state, there is just no comparison.

One project team’s perspective
We (my project team and I) have a current Project Owner and SME who both attend 95% of our daily standups – between them attendance is around 99%. We have a Programme Owner who, without invitation, has jumped onto our build environment to play with our online claims prototype, and then emailed the team with several suggestions and enhancements. 66% of the members of our Steering Committee attend 100% of our showcases.

Our Project Owner is such an advocate of the project that she has voluntarily presented work to date to various Managers and Executives in addition to and outside of our scheduled showcases and usability sessions. Sometimes this has been arranged without mentioning it to the rest of the team, which has presented interesting results when we’ve been testing and deploying – but hey, the enthusiasm and support from her of the technical team is to be commended! The team feels valued and by default collaborates more directly with her and other SMEs and so the ‘meeting of the minds’ is further strengthened.

We still have a ways to go, but how have we got to where we are? Often SMEs want to see results before they’ll provide buy in, so we can probably all talk of experiences of the chicken and egg scenario of how we can prove their co-location on a project will provide dividends prior to having them co-locate with us!

Keys and challenges to success
I can’t speak for other projects however for us it’s been, I think successful, largely due to seizing any opportunity to engage SMEs in value added Agile activities, so you can quickly turn around and demonstrate the results. We lost our Business Analyst recently (to our Sydney office. Ahem.) and had a lag time prior to having a new recruit join the team.

In the interim we had a half share of another Business Analyst who was also working on the support team. We therefore had a desk free, in the team space, for a half day every day. Our project owner agreed with our proposal that in providing a dedicated SME to cover this half day with the team, we could maintain progress during a vital period of development (beginning of sprint 3). Team velocity dipped slightly during this iteration as you’d expect with resource interruptions, handover and new arrivals getting up so speed, however by the end of sprint 4 our velocity had jumped by 13% compared to our average to date at that time, and a whopping 30% increase from our dip in sprint 3.

Part of that jump was also reflected in the drop in change requests coming across, although I could also suggest that that having a co-located SME seeing Agile development ‘in the raw’ provided a unique insight much more quickly in terms of understanding the impact that decisions can make on changes – the SME himself referred constantly to our focussing question (relating it to whether the change requests were adding value to the project/end user) … in addition, to turning around decisions of what was IN (and therefore what was OUT) much more quickly.

A genuine partnership has formed
Our project team is now back to being fully resourced, so logically we could have lost our SME … however, he still spends every morning sitting with the team, and helping out when needed.

Do you speak my language? Reaching a common understanding in Agile speak

Monday, January 4th, 2010

Author: Susan Akers

I loved this term “a unified vocabulary” when I recently saw it in David Farkas’s article on How UCD and Usability can live together. His comments particularly the one below really hit home with me as I have been working on a particular project which seemed to me, not to be considering the user experience at all! I have sometimes seen this lack of a unified or common vocabulary in a team at the start of projects, particularly Agile ones:

“.. the breakdowns that exist in integrating User Centred Design and Agile exist as a result of miscommunication from poorly set or unframed expectations. As Agile and UCD further develop and members of each camp have training to both methods I see the miscommunication fading as a unified vocabulary and set of deliverables form”

To me training is definitely part of the answer but it’s not sufficient unless all parties are prepared to also change their attitudes. Coming from a business background, I was totally frustrated in trying to explain my expectations to my technical team because I felt that they were always talking ‘techo talk’ to me and not explaining what they were doing in plain English. Then I completed the Taste of Agile course through the Agile Academy.

What a difference a day makes! I learned that if I was to speak and understand a foreign technical language of storycards, iterations, stand-ups and estimations, I really needed some Agile lessons. These terms had all been just noise to me beforehand. However, just training the business is not sufficient for successful collaboration. Both sides have to change their communication style and I think this recent tweet @GreenHomeShop sums up what all parties need to learn and accept:

.. two people can look at the exact same thing and see something totally different. ~James Rhinehart~

In conclusion, don’t play the blame game, be like me and accept that Agile is all about building a unified communication bridge and getting over it with your whole team!