Better Projects

Help! They're running an Agile project, how do I know when to worry?

2013-05-13T12:58:00.001+10:00

The parents of teenagers and new-to agile project managers seem to have rather a lot in common. There are a few similarities that spring to mind immediately, such as; grey hair and large mobile phone bills. They are also likely to be experiencing an underlying sense of uneasiness, coupled with cautious optimism and occasionally sheer panic. I have teenagers and am working with a new-to-agile project manager, so I feel qualified to comment.

Neither teenager(s) or Agile projects do well under helicopter style management, but the parent, or PM's urge to operate this way is very hard to resist. It's tough when you find that your customary approach to feeling in control of a situation no longer works and it's very hard to resist worrying all the time, about whether you should be worried or not, especially when the subject of your worry is adamant that its "all good".

In a plan-driven software development project, the number of requirements completed versus the planned requirements completed over time appears to provide meaningful information about a projects status, any deviation from the plan is seen as a red flag. When there are a lot of these, you know exactly when to worry. In the context of an Agile project, things are not so clear cut, the team may be delivering done requirements on a regular basis, but the extent to which these represent business value is the key indicator. There are obviously challenges in quantifying something as subjective as business value, but this represents the only the tip of this particular iceberg. Both Agile approaches and plan driven approaches have the same goal, which is to improve the outcomes of the software development process but they approach this goal from fundamentally different philosophical perspectives. This philosophical divide becomes very evident when an organisation tries to introduce Agile methods at the team level, but fails to do so at the project governance level.

When I needed to select a research topic as part of my ongoing studies, I decided that it would be interesting and possibly useful to investigate this. I was particularly interested in finding out how this issue is solved by organisations who's governance and reporting infrastructure is designed to use data from plan driven projects, but which develop software using Agile approaches. This research will take several months to complete and as always step one is a search and review of the academic literature in order to understand current thinking and knowledge.

Whilst there is a lot of fantastic and relevant material in the professional literature (everything which doesn't count for the purposes of ERA) my review includes only the academic literature which presents empirical research and has been published by ERA ranked journals and conferences. Doing this review was an interesting exercise I learned a great deal but the output does not constitute light reading, so for fun, I've winnowed 12 years of literature and the 6000 words I wrote down into 3 paragraphs.

I found that between 2002 and 2006, a lot of research was conducted which looked at Agile transitions in general, while there was some discussion of project governance and reporting most focused on the implementation of Agile methods and the experiences of those at the team level. Where governance and reporting was covered it was identified as an emergent problem. Between 2006 and 2008, a number of case studies were published which did focus on this issue, my personal favourite being a detailed study of the Agile transformation undertaken by an American energy company DTE Energy where the introduction of Agile methods and the focus on delivering business value at the project level is credited with being a key factor in the organisations achievement of CMMI accreditation.

Post 2008 the topic seems to vanish from the academic literature, there are a few papers which discuss very specific ideas such as using earned value analysis (EVA) to report on Agile projects. There are also a number of studies which report on organisations where a move to an Agile approach was undertaken at the whole enterprise level and where working with stage-gate governance approaches is simply not a factor. In some cases Agile methodologies were seen as the only way to manage the complexity and variability of a specific project, in other cases, such as at Cisco Systems, the use of Agile approaches as best practice was taken so seriously that the organisation invested in an Agile office as an adjunct to the Project Management Office (PMO) in order to ensure that everyone was on the same page. I suspect organisations which take this kind of approach are unusual and that 3 or 4 years ago it was still the case that the adoption of Agile methods was most often driven by software development practitioners rather than from the C suite.

Whilst the academic literature didn't provide any clear answers, of the 20 - 30 papers I reviewed a number of strong consistencies did emerge and included the following, all of which, I think most practitioners would consider to be in the "duh" category

Stage-gate approaches to project governance are potentially very compatible with Agile methods.
The key success factor for organisations considering Agile implementations is the incorporation of Agile values across the enterprise including at the leadership level.
The key failure factor for organisations considering Agile implementation is an inability or unwillingness to engage with Agile values at the leadership level.
All Agile adoptions, are in fact Agile adaptations there is no "one right way" and that a pattern based approach rather than a prescriptive rule set is needed.
That Agile coaching is almost more necessary at the C level than at the software team level, since software teams don't seem to have any difficulties seeing the benefits.

There you go, validation if you needed it!

From a practitioner perspective things seem to have changed a bit over the last year or so; entering Agile as a keyword in a job search returns as many results for project manager roles and business analyst roles as it does developer roles. A quick search of the professional literature suggests that within the project and program management community reporting on your Agile project and the challenges this presents has been a key topic for quite some time now, but is still been driven by practitioner community. This looks a lot like the early majority, perhaps the C'suite will be the late majority, hopefully not the laggards.

At the very least figuring out what is going on here, will very likely keep me out of trouble and distract me from worrying about my teenagers for the rest of the year.

If anyone would like the full list of refereed papers and articles, please let me know and I will be happy to provide it.

Crowd funding the Australian Lean Kanban conference

2013-05-07T20:23:00.001+10:00

So we all know the international Lean Kanban conferences are awesome and you probably know by now we're planning a Lean Kanban Australia/New Zealand conference 12-13th September this year. (Follow @LKANZconf if you missed it!)

The more interesting story is in our approach to validating the idea in a lean way. We're giving crowd funding a try and we're hoping this allows us to judge interest from the community, from sponsors and from speakers over a short 30 day test cycle.

So far we've picked the dates, started contacting speakers, researching venues, created a logo and setup our twitter feed.

Help us test our ideas: Visit http://www.pozible.com/lkanz and pledge to buy a discounted ticket or choose a reward that suits you. There are only 40 discount tickets available so get in fast to secure a really cheap price for the conference, and to show your support.

Also, talk to your company about the opportunity to sponsor the conference, they can sponsor direct from the pozible campaign or contact any of the organisers.

Finally, please put the word out via twitter or your own blog. Help us bring the world's best Lean and Kanban speakers to Australia. Let me know if you have any questions!

Ben

McDonald’s Theory — What I Learned Building… — Medium

2013-05-01T10:02:00.001+10:00

McDonald’s Theory — What I Learned Building… — Medium:

I use a trick with co-workers when we’re trying to decide where to eat for lunch and no one has any ideas. I recommend McDonald’s.
An interesting thing happens. Everyone unanimously agrees that we can’t possibly go to McDonald’s, and better lunch suggestions emerge. Magic!

This. Most definitely this.

Next time a stakeholder won't give you an answer, consider giving them one. Make it a bad one. So stinky it almost runs them out of the room. Watch them trip over themselves to try and give you the answer you wanted in the first place. Love it.

Flying into an Agile transition

2013-04-25T11:56:00.000+10:00

So just what does a transition to Agile look like? I have recently read a a number of academic papers, journals and books on this subject (consequent to an ongoing PhD). As a result, I have learned a lot about the underlying theories and philosophies of Agile software development (including numerous accounts of Agile transitions); many of which have been the subject of rigorous empirical research. I have also learned, that there are any number of freely available lists, taxonomies and frameworks; many composed by well known authors, thought leaders and industry experts.

However, I have not yet come across one which describes anything quite like the day to day experience I have been living for the last 6 months: co-leading a team of IT professionals from working in a world which was definitely not Agile to somewhere that is now describable as Agile.
Most of the empirical research I have read has been of great value; I believe that bringing an understanding of theory to your practice is vital: it helps you to become a better practitioner. But none of the beautifully written theories or frameworks describe the world that I live in right now. Practical advice for day to day survival in an imperfect world seems thin on the ground.

The thing that has helped me survive (so far) the feeling of imminent drowning in items to address, has been what I learned from a website all about housework. The rest of this post is a light-hearted attempt to draw a comparison between transitioning to Agile, and the process of getting your house in order as described on www.Flylady.net.

I found Flylady a while ago; I was engaged in a domestic engineering project involving two babies and a part time undergraduate degree. I stumbled across the website and saw myself described on the homepage. I was suffering from C.H.A.O.S (can't have anyone over syndrome). If anyone ever did want to come over and visit, I would do just about anything to avoid it; I did not want anyone to see the unmade beds, scattered toys, fingerprints and laundry (Mt Washmore rivaling Mt Rushmore) to be done.

The house was a total mess most of the time, I was disorganised, often late and felt totally overloaded. I could not get past the idea that if I could just get it all tidied up at once, and in a finished (done) state everything would be better, but the whole thing was too overwhelming to even start.

The Flylady website was offering a cure for free, so I accepted. I found lots of useful materials on the site, especially for those who really do want to become a domestic god(dess). Generally the website message is light and positive. Some folks might consider it all a bit cheesy; Flylady stands for "Finally Loving Yourself" however, if you can work through, or skim over this, it delivers some key messages and ideas which could apply to any complex endeavour. I'd like to reference some of this material and the way that I have found it useful in my current context.

1. Don't try to catch up, jump in right where you are

It would be nice to have things all planned out, it would also be nice to have the time and resources to implement a textbook Agile transition, with an appropriate project, training, management support and enthusiasm all in place first. Does this ever happen?

If there isn't the will, the time or the resources, you just have to start somewhere. You can't drive yourself crazy trying to convert all the use case documents to user stories before you begin. It's ok to just start from the next sprint, it's also ok to try a process or approach, learn from it and change it. We started with stand ups and began to grow into our transition from there.

2. Daily habits one new habit a week

Flylady starts with asking you to add one simple practice to your life each week. The first idea is that you shine your kitchen sink every night (this implies doing the dishes), so that when you wake up in the morning, it looks good and makes you smile (this one works!). Also, the contention is offered, that if the kitchen in a house looks tidy the rest of it also looks better.
Practices are added each week throughout the year and if you follow all the advice on the habit list I'm quite sure that you would end up a domestic paragon. I never managed this, but mostly still adhere to shining my sink, getting dressed to shoes and prepping my clothes for tomorrow every day. Having one day a week for school and family paperwork, and planning the menus for the week are also valuable Flylady habits. I have not achieved a self organising team to do the cooking though.

We have added one new scrum practice every week or so, we refine them as we use them. Most recently we started to really emphasise the importance of each team member understanding wider priorities and selecting work based on these. We are making good use of our retrospectives to prioritise practices to review, but it still tends to be on a firefighting basis.

3. Zones

Divide your home, or your endeavour into zones, my house has rooms, my project has areas, such as requirements, development, QA, Dev-ops and process improvement. Focus on each of these in a rotating cycle, and "De-clutter" (clean up) in the current zone for 15 minutes a day. The kicker that goes with this advice, is that "you can do anything for 15 minutes" (set a timer).
You can get through quite a few of those old use cases in 15 minutes a day every day.

I could draw many more detailed examples, but I think that's probably quite enough for a blog post. Especially one which includes housework. I will be spending the remainder of this year working on a research project which will try to understand and describe what Agile transitions are really like, I hope to propose some practical solutions for others to use. Consequently, my house is total chaos again. This time, I don't really mind, my babies are now teens and we all love having people over.

Are you talking about last year's thing still?

2013-04-19T14:11:00.001+10:00

It's hard to keep up, I know...

Apparently, it the fault of the women

2013-04-16T08:52:00.002+10:00

"The inspection foreman a god job of breaking in those girls..."

Let's keep challenging bad practices and assumptions.

Blueprint for a Sprint Retrospective

2013-04-15T21:43:00.000+10:00

The Retrospective

Sprint number (Some unthinkably large number)

Duration: November 2012 to April 2013

Intro:

Not strictly part of a retrospective, but we are Agile here so we adapt to stakeholder needs.

I have just spent a week on holiday for the first time in more than 12 months. It was a wonderful holiday to a stunning part of the world. I spent time with my kids, explored rain-forests and saw a crocodile or two.

I did not engage in work, even though I noted emails flying past my inbox, but, I did dream about work every single night. This indicates an overdue need for a personal and professional retrospective

Things that went well;

I learned how to uncover the size of a hidden technical backlog and plan sprints around it.
I learned how to share knowledge, quickly and without lecturing
I learned how deliver less than desirable news
I got to meet and work with a number of interesting and deeply intelligent human beings
I learned how to set up and administer Jira and Greenhopper like a boss
I delivered what I said I would deliver, when I said I would deliver it
I didn't hide and I took responsibility for my actions when I got it wrong
I submitted all my study assignments and scored respectably for them
I didn't neglect my family quite as much as I could have
I discovered my family are more self-sufficient than I thought

Opportunities for Improvement;

Do better due diligence ALWAYS
Correct, detailed requirements are really really important, but the details about how they are shared and recorded is not.
Leadership is not given it is always taken, but “followship” must be given freely
Yes assumptions do make an “Ass out of U and Me”

Critical Outcomes;

I learned SO MUCH, I discovered that I am capable of doing so much more than I thought I could
I handled situations I had never come across before (because I had to)
I reaffirmed for myself, what I really want to do and more importantly, what I do not want to do
I care about doing what I do well, not just the technical practical side of being a BA or a PO but both; I think/know that I can be a better BA if I use Agile methodologies. Either, by itself is not enough and never will be
I want to make beautiful, usable software, but in the best possible way.
I want to really;

understand how this can best be done; and
teach others how to do it

Action Items;

Transfer from my current professional doctorate to a PhD
Find a job which pays the bills, but doesn't follow me on holiday
Write the darn PhD
Find a nice university where I can research this stuff, write about it, talk about it and teach it; without starving in the process
Finish seeing my kids through high school first

What can Agile learn from Punk?

2013-04-02T21:54:00.001+11:00

Plenty, it appears.

Meddlers game; Designing Agile Organsiations

2013-04-02T15:37:00.001+11:00

I really like the learning activity Jurgen Appelo has created in his Meddlers game. I want to share some insights I have gained from playing Meddlers here with you.

The basic set-up

The original rule set is on Jurgen's Noop.nl blog.

There are team tiles and role counters. The team tiles are marked as either cross-functional or as specialists. There are also customer tiles. Join the hexagonal tiles of teams need to work together.

You set up the game with a team structure based on an initial brief. I like asking people to start with their existing team and teams they depend on to deliver customer value.

You can then add scenarios or ask the team to come up with their own scenarios and explore how they might respond.

My modifications

Jurgen’s structure and rule set is pretty lightweight. I have a modification I like to use to help me amplify a sense of journey into the game.

I add;

There is an initial set-up round per the original rule set
I then work in 5-8 minute rounds
At the end of each round I call out an event from a deck of event cards I made up
The team need to respond to the event cards in the following iteration
The event cards can be given to the teams and they can play them at heir own rate if you want to let go of control

What can you learn?

Some of the available lessons are listed below.

Is it easier for one person to design an organisation or to do it as a group?
Is it better to manage a set of Self-organising, cross-functional teams or to manage specialists groups? What about hybrids; where do they fit in?
What does organisation design do to system architecture?
How does an uncertain environment help or hinder organisational agility?
How should teams and customers organise their relationships?
What is an optimal team size? How do you manage growing pains for teams?

In fact there are also many more learning opportunities in this game. Meddlers is what I like to call an open ended learning opportunity. You get to bring your own background, your experiences and knowledge and your biases as well. You then get to mix them up with other people’s own sense of the world and through that interaction you'll develop your own insights.

Additional information

You can download the game here; http://www.management30.com/product/meddlers/
I’ll be facilitating this game at Scrum Australia in April. Come along of you are there.
You can also arrange to run this game in house, either stand-alone or as part of the Management 3.0 training course. Get in touch via Tabar.

Asking for feedback

2013-03-27T10:28:00.001+11:00

I regularly ask people at the end of meetings, discussions, etc "Was that valuable for you? Why or How?"

Constant incremental feedback helps tune the way you work.

With that in mind I am thinking about polling my stakeholders regularly with a simple survey. As a read of this blog you are one of my stakeholders.

Feel free to give me feedback via this survey form at any time.

If you have suggestions for me about this idea, they are also welcome.

Loading...

What the world needs now is another (Agile) consultancy

2013-03-25T15:18:00.001+11:00

It's been months of discussions, and litres of beer, wine and coffee, but finally we are doing it. A number of colleagues of mine in the Melbourne Agile community are joining with me in starting a new (Agile) consulting business.

It is going to be called Tabar. It is a place for agile practitioners to come together and share.

We are going to do that whole modern agile business thing where it's a membership model. In principle the organisation will be owned by the team. Revenues will flow back. It's not certain how some of the details will play out, but the key thing is that the organisation is a community, and that it's main goal is to provide value to the community members.

Ben put it nicely when he said the value proposition is in people being connected to each other.

We have looked to Crisp and Happy Melly as examples. Our secret ambition is to have more people tell stories about our venture than these other teams. (Oops, not so secret now.) But really we look to these and similar companies as parts of a broader family more than competition. The future of work lies in collaboration.

Why the (brackets) around the word? Because we don't want to be 'just' agile. We have a range of skills and insights tat we can bring. Agile is big in the market right now, and that community is how we know each other, but we also consider the agile toolkit broad, but not sufficient for all circumstances. (For example, is Kanban without Scrum/XP agile?)

There is a much more comprehensive and coherent statement of what this is about, but you need to have it face to face. Next time you see me, come and grab me or one of the other team members and we can explain it to you if you are interested.

We'll also declare this at upcoming community events, including Scrum Australia which is coming up in 2 weeks.

Does a Scrum team need a Product Owner?

2013-03-24T21:55:00.001+11:00

This is the sort of question that can't be easily answered in a public discussion because there are so many interpretations and assumptions embedded in the question. Let's unpack.

What is Scrum?
Scrum has been around since the early 1990s. It arose from software development teams.
It's a framework for doing things better, with a strong orientation to building software. Scrum's authors are Ken Schwaber and Jeff Sutherland, and there are two organisations, Scrum.org and Scrum Alliance that provide some sort of governance over the Scrum community, providing tracing, certification and publishing rules and guidelines.

What is a Product Owner?
Your product owner readies and orders the backlog for the team. To do this they reach forward in the value stream, out to markets, customers and other stakeholders to make sure the team is building the right thing.

You can read more on this from some of the official sources above. To start, there is the Scrum guide from Scrum.org, and the Scrum Alliance has it's Core Scrum summary. I find this extract from the Scrum Guide particularly useful.

The Product Owner may do the above (typical list of P.O. activities) work, or have the Development Team do it. However, the Product Owner remains accountable.

The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a backlog item’s priority must convince the Product Owner.

For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No-one is allowed to tell the Development Team to work from a different set of requirements, and the Development Team isn’t allowed to act on what anyone else says.

Ken Schwaber elaborates on his blog in a number of posts on Product Owners. Schwaber is quite elegant and simple in his description. Some points I take away from his writing are;

Product Owners are a great tool to help organisations understand the value Scrum teams adaptability and flexibility can bring.
Product Owners come with the power to make decisions; it's not about story writing. It's about finding where value lies.
General and Product management and Software-Scrum teams still don't typically understand each other and the Product Onwer, with the Scrum master helps bridge the two tribes.

Jeff Sutherland can be found commenting in this 2007 article

Schwaber, Sutherland and their team have also updated Scrum canon and added new descriptions and courses around the PO role in the last year or two.

Beyond the description

You see Schwaber's blog posts (and books) always give a situation and then respond with aspects of Scrum, explaining why they are useful. Understanding the situation and the "why" of the response is illuminating.

Schwaber also highlights the roots and the trajectory Scrum is travelling to further help understand how it all comes together in these case studies to work out.

Given the state of most organisations, there is a definite opportunity for organisations to learn to use their software development capability. Scrum provides a framework that is often comprehensively prepared for the challenges the organisation has.

Even better it has a really simple meme. Scrum is an idea that is simply packaged, and so it is able to be quickly transferred from person to person and from team to team. Unified visions of what the future might look like go a long way to aiding change.

But Scrum isn't the destination

And that's where the discussions get messy.

Is it still Scrum if you don't do daily scrums?
Is it still Scrum if you don't have retrospectives each sprint?
Is it still Scrum if you are pulling a PBI from your backlog directly after finishing the previous one, rather than in iterations?

What about a team that has been scrumming away for six years? They have over 300 retrospectives and associated variations in the way the do work. This week they decide to abandon sprint reviews in favour of a bunch of continuous delivery techniques?

Do they stop doing Scrum at that instant?

Apparently, they do. But that's okay.

Ron Jeffries has a nicely formed answer at Agile Atlas.

"In short, you should be asking "Will I be more likely to succeed if I don't have a Product Owner?" or "Will design iterations improve my chances of success?", not whether you'll still be doing Scrum or XP or YourBrandHere if you do those things."

Ron's article expands on the idea of learning from the experience of others. Take the time to not just master, but to understand the practices and reasons why the work.

You'll hear me talking about dropping Scrum practices in one context or another. Sometimes it is because the organisation doesn't want to deal with Scrum. Sometimes it is because I am working at a different level to team delivery. Sometimes it is because the team is using XP or some other variation. Rarely, but sometimes, it's because a team is able to be more effective by moving past the fundamental practices.

I have had my best agile experiences working in and with Scrum teams that do it by the book (often also pulling a lot of XP along as well.) I have to say I'd trust these guys. It's not two crazy people with an idea that just might work. It's a community of thousands with decades of experimentation and observation under their belt.

So, here we are at the end of the blog post.
Do you have the answer yet?

No, there is no Scrum without a Product Owner.
Yes, you can be effective without Scrum.
Learn the basics by being successful with them before you challenge them.
Product Owners are powerful and important roles in Agile frameworks.
We should explore this, but if we do, we won't be doing Scrum.

Five whats

2013-03-18T20:47:00.004+11:00

You probably know the Five Whys. Challenge the assumptions by drilling in with more "Why?" questions. you might sound like a four year old but you'll push past superficial reasoning.

Can we level up this technique?

This Simon Sinek video is also pretty well known. "People don't buy what you do, the buy why you do it." It explains a rationale about how our rational brain connects with the what, but our emotions connect with the why.

It's 5 minutes and quite compelling. Check it out.

But "Why" can be a pretty annoying question to ask, and can be difficult for many people in rational mindsets and analytic cultures to respond to. So how can we step our way up to why?

Ask yourself what do the people you are interviewing want to talk about. (See what I did there?)
And then you can ask how best to engage with them. (See that again?)

Once you have worked your way through this you'll be able to work you way up the question hierarchy Sinek talks about.

At this stage I get to check whether you watched the video. Did you hear how he said leaders think about the shy first? Research and discovery work needs you to engage with anyone, and so you sometimes need to start somewhere else.

So here are some "What questions to help you on your way;

What is it we are doing here?
What circumstances led to this?
What if we stopped doing this?
What does the customer think about this?
What would mean we can move on from this?

All open ended, but all about the what.

How could you make this work for you?

The (boring) UX and Agile discussion

2013-03-11T10:39:00.000+11:00

I saw this article on UX strategy and Agile: Is UX Strategy fundamentally incompatible with Agile or Lean UX.

It's a reasonably well put together article, but I'll save you the trouble. Apparently they aren't compatible.

I value UX. I worry about knowledge management and how hard it is in large organisations and communities. UX is a form of knowledge management. I struggle with agile in the enterprise. Agile is hard and enterprises like short-cuts. I think about these things and I try out experiments all the time. I want a better world.

Maybe I am in a grumpy mood, but it irks me when people put up a straw man and then argue their case. It's a cheap debating tactic and I didn't like it when agile folks did it to project management and I don't like it when other practices do it here.

Let me unpack the argument a little more succinctly for you;

If you are sloppy with your work and you fail to think about the whole picture you will end up doing a shitty job.

Here is a picture comparing UX (strategy) and Agile and highlighting its issues of compatibility.

Genius, right?

Let's work together people. Stop trying to be the cleverest kid in the room.

Why does Yahoo need you in the office and why does Best Buy care more about the way you work than results?

2013-03-08T10:30:00.000+11:00

You probably know about the demise of Yahoo!'s work from home policy and you may know that Best Buy have abandoned their Results Only Work Environment approach to management.

Both companies are explaining their change in approach in the context of a call to arms to re-engage the workforce in transforming the business. There are lots of quotes about collaboration and the creativity and energy that comes from working with your team.

And it's probably fair enough. And it's true that changing times call for new ways of doing things.

But why didn't these idealistic approaches accommodate the change these companies needed?

I suspect that it has to do with commitment.

We commit to people. We are loyal to people. When we don't mix with people in a social setting we lose our place in the community, and a feedback system spins up where loyalty atrophies.

So an alternative to abandoning ROWE and WFH would have been to build better online collaboration spaces. I imagine that would have been a superior approach for Yahoo! as it could have helped them spin up new business propositions.

A project case study where Yammer came to the rescue

2013-03-06T12:00:00.001+11:00

You can never trust a case study to show you the true roots of success and failure. There are usually too many complex relationships between the moving parts to properly parse out the lessons. Despite that I want to share a story about a team using Yammer to overcome some of the challenges that beset it. Yammer is not the solution here. Decentralised decision making and wide open collaboration are. Yammer was just the tool at hand on the day.

The situation

A project got out of hand. Lack of sufficient formal leadership and an over-hierarchical organisational structure and culture appeared to be the main roots of the problem. The project manager was calling out for help but no-one was able to hear him. Eventually the project crashed.

The project manager was stood down, the consultants were called, the project sponsor was wondering what happened. A search for a new project manager was initiated; someone who was high end and able to rescue this apparent disaster.

What happened?

While the consultants sorted through the rubble and the search for a new program leader was undertaken the software guys opened up a Yammer group and asked the users if there was anything useful they could do while they waited for new orders.

The user community responded with pain they were feeling day to day.

Many of these issues were small and could be fixed within a few hours to a few days. One by one the small team addressed each of the user pain points. The user community got more involved and active in alpha testing releases and offering feedback on what to work on next.

The software team continued to work on small incremental changes, without direction, without requirements specification or even user stories. They were just working off dialogue in a yammer group.

The outcomes

Everyone in both the user community and the software team was happy with the improvements. Many long term usability issues were fixed. Business outcomes were achieved. Value was created.

Unfortunately what the user community was articulating were operator issues, and not specific to the program agenda.

When the new program manager was appointed he maintained some capacity for this to continue, but had another job to do as well which was to shift from internal to externally managed infrastructure. This was unfortunate as it limited the team’s ability to work to the user community’s agenda.

The new agenda was mediated by a desire to reduce operations cost (which wasn’t achieved by the outsourcing by the way) and by a middle management layer inserting it’s own agendas into requirements.

Lasting effects

The lesson was there, and understood by the people in that community. User engagement and participation in alpha testing remains in place a few years later. I understood they were going to stick with a release and recover strategy rather than a test first approach but the organisation was inclined to suppress that sort of behaviour.

The overall approach to connecting developers and users and prioritising work through that channel wasn’t sustainable though, as the developers were funded by a project with a specific end state. Once that state was achieved the team was essentially dispersed and the system left in the state it was in with only critical failures attended to.

What’s the lesson here?

Over and over again we see teams do great work, but they are let down by the environment they operate in. Theses successful teams are necessary to stimulate a change the way we do business, but we need to work harder in adapting the whole system to innovation.

What can you do?

What can I do?

I suspect maintaining some capacity in your day and week to talk to the people who manage the supporting infrastructure and make sure you can deliver wins to them that encourage them down the same path you are travelling.

Irrational Rules with Markus Andrezak

2013-03-06T11:17:00.004+11:00

LKCE12: Markus Andrezak - Irrational Rules from Lean Kanban Central Europe on Vimeo.

Spot check! (Audit yourself today)

2013-03-04T16:26:00.003+11:00

Spot check!
Answer these questions for each of your projects? How do you feel about the answers? What will you do?

Do we have a defined goal for the program?
Is there any objective measure of success or failure?
Does each program have a goal and measure of success/failure?

Do we have a portfolio sponsor?
Does each Program have an owner/sponsor?
(are we all using the same language around sponsor and owner)
Does each program have a governance structure? eg steering committee and working group? Product owner?

Do programs require funding?
Is the program funded?
If not, is the sponsor championing the funding? Is it at risk?
Does the funding cover all costs?
What about operations costs?

Are there any hard deadlines?
Are there any cross project dependencies?

What is the value we can add to each program?
Have we discussed and agreed our contribution and role with the program?

Do we have an appropriate solution pathway?
Is there is a reliable system for delivery? Will anything get in it’s way?

What environmental and situational risks affect the programs?
What/how does a blocker get cleared for these teams?

Ultimate Battle game: For Communities of Practice

2013-02-25T16:26:00.002+11:00

Ultimate Battle is a fun and interactive league table game where groups of people can share and learn about ideas and techniques they use in their professional community. It can take as much time as you have available. I find it works well in 30, 60 or 90 minute sessions.

The game takes the form of a play-off battle, searching for the most “Ultimate” technique or practice from the participants existing toolkits. The search includes challenging and exploring the techniques so people can hear their strengths, weaknesses and situational aspects that make them successful.

Learning Objectives

· Help elevate a community’s knowledge of techniques and practices.

· Help people hear about and learn of new techniques and practices they may not know about

· Amplify people’s awareness of situational and contextual aspects that make practices and techniques successful.

Audience level

This is an open ended learning game so all levels of experience can make use of this activity. Diversity across the participants helps amplify the learning opportunities.

Mechanics

Assess your available time and people in the activity. You will need to form a league table to track practices as they compete and either play on or are knocked out. Draw this on a whiteboard or butchers paper to help identify team sizes and number of rounds you will need.

You should time box each round to between 2-5 minutes. You may need to have multiple league pools to work through large groups in sufficient time.

Round 1

1. Each player writes down a preferred technique or practice that is applicable to the community that is meeting.

2. Players (or teams) pair off and each team has 30 seconds to explain the technique

3. The opposing player then gets 30 seconds to challenge it

4. Each proponent then has 15 seconds to respond to the challenges

· Players can update their cards with notes about strengths, opportunities etc as they go

5. Based on the evidence provided the pair select a winner

· (An alternative is that another team or audience selects a winner)

6. The winner collects the loser onto their team and moves to the next round

Subsequent rounds

· Steps 2-6 are repeated with teams growing in size

· For added interest you can post up the losing techniques onto the league table as they are knocked out

Finals rounds

· You may have one or more final rounds depending on room size and how many league pools you ran

· The goal is to play off the final rounds in front of the rest of the room

· Have at least 4 groups in the finals rounds. While 2 teams play-off the other two teams are the audience. The audience votes on the winner of each round rather than the participants

· Given the teams are larger in this round you could consider rotating the roles of each team member; First person calls out the method, Second person talks about features and benefits, third person responds to challenges from other team, fourth person challenges the other team’s technique

At the end a winner is declared; expanding our knowledge as a community.

Equipment

Pens, blu-tac, index cards, butchers paper, etc

Today's Prioritization Task

2013-02-21T02:56:00.003+11:00

Today's Prioritization Task...

You have ten $1 bills (or whatever play money Craig uses down-under).

I need you to rank each of those ten bills in priority from lowest to highest, based on which of the $1 bills has the most value. How would you do this?

Go.

How to Run a Teleconference Like a Boss!

2013-02-20T16:45:00.001+11:00

Here is a cool teleconference technique I want to share;

The problem
Lots of people on a conference and nobody interacting. As the facilitator you want people to participate and you know that there is lots of good insight and opportunity in the group, but you struggle to pull it out into the collaborative space.

A simple technique
Break people up into small groups who collaborate on Communicator in the background. Have them share back to the main group (maybe via a spokesperson) in the main phone conference.

An example
Our team has tried this a few times now and each time the feedback from participants is that it works well (compared to the way things were.) From our perspective it also yields good useable insights that we can take away from the meeting and inject into our program.

We spent several minutes briefing people in on the objectives of the session and the approach, emphasising that it was an experiment. We assume this positioning helped open people up to exploring and trying the technique with an open mind. We also broke people into groups of 3 with no particular social engineering agenda at play, but happy with the diversity in teams that our randomness generated.

We got each small team to fire up a Communicate group with their two team mates and confirm on the phone that they were ‘live.’

We then briefed them on the goal and approach again – there will be a 5 minute iteration (we could have run multiple iterations for more complex problems) and then a spokes person will share back the key points of the discussion.

The phone bridge then went onto mute while the teams worked. I opened up the phones again a minute before the end of the working time and called in the last 60, 30, 10 seconds.

We then went around each group and collected key points and discussed across the group. At this stage most people in the meeting were sufficiently engaged and warmed up to participate. (This example had about 22 people all up.)

We captured the key messages and ideas and collated them in a MS Word doc which we distributed after the meeting. An improvement on this aspect could be to use Google Docs as your collaborative document tool as you go in the room.

Some constraints we considered when designing this activity
We decided when planning this activity for the first time that we should stick with tools that everyone uses day to day, so no web-ex or other internet tools, no fancy multi-space chat rooms or any of that. Just keep it simple by sticking with tools that were on everyone’s desktop.

Some feedback we have had
Overall it works and is an improvement on the normal leaders tell/passive audience teleconference meeting form. Short cycles works because it keeps people focused. Also longer cycles would be better because it allows more time to get to know each other when you haven’t worked closely before.

Why this works
Large groups don’t feel like a place you can open up in. Phone conferences add another dimension to this as you don’t know who is on the line. People don’t feel safe speaking out and prefer to stay in the status quo of “passive audience member.”

By breaking the large group up into smaller groups people can more easily interact as individuals and make a fuller contribution. The further away the interaction method is from face to face the smaller you need to make the groups. But don't go below 3 otherwise you lose some of the magic of collaboration.

Scrum Australia, April 10th and 11th

2013-02-18T20:31:00.001+11:00

Hi people,

If you live in Sydney and want 2 days of Scrum conversations with your peers out there in the agile community check out Scrum Australia's April conference.

Jump in early to take advantage of the very significant early bird discounts.

I'll be running Jurgen Appello's Meddlers game (which is a load of fun) on the morning of day 1, so drop in and say hi - and stay and play the game with me.

The whole program is published at the Scrum Australia website. So are Ed Wong and Anton Rossouw. Frank and Herry will be reprising their talk on offshore scrum teams. And newcomer to Australia Berndt Schiffer will be making his first Australian conference presentation. Lastly Martin Kearns from SMS will be closing with a keynote.

So it will be just like being in Melbourne :) Only warmer.

Did you have a meteor strike on your risk register this last week?

2013-02-15T21:53:00.003+11:00

I like eating my family and pets

2013-02-15T21:46:00.000+11:00

This picture is a promo shot from the movie John Dies At the End.

The heading of this post is from a joke about punctuation. What's a comma, between friends?

And for us it is a reminder that no matter how much care goes into project documents, they are still subject to misinterpretation.

An example of a poorly designed user experience (from Amazon)

2013-02-11T11:00:00.000+11:00

Even Amazon, the ~~giant~~ behemoth of internet selling makes ugly design mistakes.

Here is the scenario I ran through last night;

I finished reading a book on Kindle on my tablet and decided I wanted to buy the sequel. I went to the Kindle Store in the Kindle app and was transported to the browser (1).

I then searched for the book and found it. Strangely the price was in pounds (2). Whatever; I click through with the intention of buying. But wait. I can't buy on what turns out to be amazon.co.uk because I am in Australia (3).

So I have to click through to Amazon and hey, I have to begin the search for the book again (4).

Lucky the have a patent on one click purchases (5) as I was about to give up.

Then I buy the book, but it doesn't ship to the tablet I am on (6). I go back and see the default destination is to my other older tablet (7). So I resend it to my new tablet (8) and it starts to deliver.

Overall it is a pretty poor user experience and one I suspect that comes from incremental additions to the feature set. Agile development everywhere is at risk of delivering poor user experiences like this.

This is akin to technical debt, but it is more apparent to customers. I suppose you could call it UX design debt. Pay attention to it because it sucks and drives business away.

Let's run through a few of the failures and what might be a better approach:

Browser navigation of Amazon sucks on a tablet. The page doesn't present for a tablet experience or the screen size. And why the hell are you taking me out of my nice cuddly Kindle space into a jarring other place anyway?
Shouldn't the browser know what country I am in and deal in my local currency? And you have my account details as well so you know what country I come from.
Why the hell doesn't the website just ignore what country I am in and deal with the regulations around regions under the hood? Why doesn't Amazon just operate as a global platform and customise locally once we get into a transaction, rather than before?
Why can't you carry my search and landing page forward as we change domains?
Seriously Jeff, patenting One Click purchases sucks. Why would you do that?
You know I initiated a search on the back of reading the prequel on this device. I am buying the book on this device. Why would you think to ship the book to any other device?
Especially one I haven't logged into - or even turned on - in over 6 months?
Selecting devices on the browser is another fiddly and non-obvious activity. Oh, and the pull down feature in Kindle isn't very obvious to a novice user either.

What are your poor user design experiences? Got any to share?