Archive for April, 2012

Moneyball has been credited within the Lean Startup community as a classic example of some of their principles.

I thought for those who haven’t had an opportunity to watch it that I would note some of the more powerful statements made in the movie. Some are slightly modified to apply outside of baseball so that you can potentially better relate it to your own environment:

  • The first guy through the wall always gets bloody.
  • This is threatening not just their business, this is threatening their livelihood. It’s threatening their jobs, it’s threatening the way that they do things.
    And every time that happens, whether it is a government, or the way they do their business, or whatever it is, the people that are holding the reigns – their hands on the switch, they go bat shit crazy.
  • Anyone that’s not changing – they’re dinosaurs.
  • There is an epidemic failure in the system to understand what is really happening. This leads people who run their teams to mis-manage their teams.
  • They are asking all the wrong questions. If I say it to someone I am ostracized. I’m a leper.

Read Full Post »

There is a growing trend within the Scrum community that believe when they are doing software development that it is actually product development. This is not the case. Software development is subset of work that is needed to be done to support product development.

In small organizations the deviation between software and product development might be small but the greater in magnitude an organization, generally gets the wider the difference gets. 

Scrum believes that you must have a cross-functional team that can get the Story/Task to “done”. Commonly this means that the team has the skills to be able to start the card with a meaningful conversation, develop it, test it, and deploy it. Often this results in Storywalls/Taskboards having headings like “Sprint Backlog”, “Analyse”, “Build”, “Test”, “Done”.

But what a lot of teams forget is that the software is only a smaller part of the organizational whole. Lets take a look other non-software components that are often involved in large scale product development:

  • Legal
    Sign-off of publicly exposed content to ensure that the organization is not opening itself up to liability; xtra-product only
  • Marketing & Sales
    Promotions of campaigns related to the product; xtra-product only
  • Training
    How users will use the product to perform their job; more commonly intra-product only
  • Communication/Change Management
    How impacted stakeholders and users of the product will be informed of what is happening with the product development and rollout; more commonly intra-product only

             xtra-product denotes a product that is sold to the public; intra-product denotes a product that is internally used within the organization

It is for this reason that I think Scrum’s label “Product Owner” is poorly named, or maybe more importantly has two few responsibilities associated with it. How many Product Owners have you met that have also taken on either the work listed above or the co-ordination of the above effort. They should. But if they did that and their standard Scrum duties they would be severely overburdened.

The cost of these extra activities are often just as large as the software development itself. Sometimes more, especially for COTS/Software as a Service implementations. Do you have Stories or Tasks in your Release Backlog for these activities? Why not? They have to be done and if are not aligned with the work that the software team are delivering then you are potentially opening yourself up to benefits realization risk. It’s all well and good to have the software on time, but if the change team haven’t been kept in the loop regarding when you plan on delivering minimal marketable features then they might be communicating that you are delivering them earlier than expected. Sometimes the success or failure of a product is never down to the software itself but how it was communicated and “sold to” someone; or how well they were trained in it.

How do you know that these other components are on track? Shouldn’t their work related to the product be fully visible and flow through from Sprint to Sprint?

If your product requires any of the above think about how you can incorporate them more into your environment and more importantly into your flow. Should the story/task be “done” if it hasn’t passed through these flow states. It doesn’t have to mean that every single story or task has to go to legal or through to training but it is a trigger – “will the training material need to be updated to reflect these changes?” If not, move it to done, otherwise wait until the necessary changes have been made before shifting it to done.

Read Full Post »

I have just finished reading “The Lean Startup” by Eric Ries for the second time and have been spending some time working with a team using the model. Joyfully it has made me think about opportunities out there and if I ever had my own push to be entrepreneurial what exactly I would consider.

As part of considering what sort of Lean Startup I would consider I wrote my ramblings down and then noticed that I felt something missing.

I would formulate the idea using the Gaddie Pitch:

You know how most…{existing commercial environment}?

Well what {Lean Startup idea} does is {how it breaks the mould from a value proposition perspective}.

In fact, {more value proposition information}/{recent success}

As I fleshed out the ideas further I considered the depths of what their value hypotheses and growth hypotheses were.

But it was missing something.

I wanted to know how the Startup idea also would create revenue for the business. After all, commercially, what good is a product if it has thousands of happy customers, a high and continual increase in customers but no means to make any revenue?

Eric Ries defines a value hypothesis as

Tests whether a product or service really delivers value to customers once they are using it.

and a growth hypothesis as

Tests how new customers will discover a product or service.

But what about the hypothesis that you will actually make money? Surely this is something that needs to be tested too.

Read Full Post »

I have been pondering since reading Steve Denning’s on Fighting the Kool-Aid of Stock Based Compensation  and Umair Haque’s Harvard Business Review’s The Economic Roots of your Life Crisis about perilous journey that we might be on. Take a step back for a moment and consider some cause and effect.

When my parents worked it was pretty much considered a job for life. Most of my friends around the same age had similar experiences for their parents.

When I entered the permanent workforce in 1997 this mentality was beginning to peter out. Big organisation after big organisations that I worked for all went through regular retrenchment periods. Some were as short as every six months, others in two yearly cycles.

They called them different names – offshoring, outsourcing, departmental restructure, voluntary reduced hours; but the intent was always the same – cut the bottom line.

Thankfully I have never been directly impacted by such acts but it has led me to a feeling of constant insecurity. I have never felt safe in a job.Our clock is ticking down

Does anyone else think that this is crazy? What is the point of ever being a permanent employee if you cannot feel safe (naturally excluding performance issues)? At least a contractor knows when their date is going to end. The rest of us that were after secure jobs to pay our mortgages and support our tribe of kids wanted something that we could depend upon. But we cannot depend upon it. We are like a character of “In Time“, our clock is ticking down, but we have no idea when the timer is going to reach zero.

Because of my parent’s experiences within companies I was raised with the belief “You look after your company because your company will look after you.” Extra hours was sometimes part of that deal. Towing the company line as well. But what I was experiencing was something considerably different. It didn’t appear like the organisations cared about its most long term employees (they were commonly the first ones to go). It shattered my illusions. It left a void in my belief system.

I am not the only Generation X person who has been left feeling like they are in the Matrix. Companies no longer care about their people, they care about the almighty shareholder seemingly above and beyond any other competing priorities.

So as anyone with a dysfunctional belief system does, they find a new belief to fulfill this empty hole. We believe that if the company doesn’t care about us then we need to care about ourselves. What behaviours and patterns emerge from this?

We appear selfish. It is all about what we can get right now. We want recognition right now. We don’t feel obliged to have to stay at an organisation for too long (especially if the organisation loves to retrench frequently). We see no problem with being headhunted. We see no problem with doing the work for the hours that we are meant to be paid and no more. This makes us look lazy.

Does this sound familiar? Take a look at the wikipedia definition of a Generation Y:

 Studies predict that Generation Y will switch jobs frequently, holding far more than Generation X due to their great expectations.[70] The UK’s Institute of Leadership & Management researched the gap in understanding between Generation Y recruits and their managers in collaboration with Ashridge Business School.[71] The findings included high expectations for advancement, salary and for a coaching relationship with their manager.

Is this singularly minded focus on shareholder value turning us all into Generation Y thinkers?

Read Full Post »

When people think of the term ‘gamer’ it engenders ideas of pasty white teenagers living their days in a zombie like state in the basement of their parents house spending over forty hours a week with their eyes glued to the pixels on their screen smashing keys on their keyboard. Despite this stereotype, 72% of American households have at least one digital gamer in their family (up by 5% from 2010) and with the introduction of small games on the iPhone and iPad and through social mediums such as Facebook, the digital gaming door has been re-opened to a whole new audience. Growth of the gaming industry is only expected to rise.

Most of us have actually been gaming ever since we played our first board game, at an age when we didn’t know how to read or write. In our early teens we turned to a different form of game, the physical version, sports. In our adult life we have been playing an entirely different and often less motivating game, the political and strategic game, work. If you add up all the time playing the ‘work game’, the ‘sports game’ and the digital games on our PCs, smart devices and consoles we are all spending a good portion of our life playing games, some engaging and fun, others less so.

Is work a game?

There are four clear conditions that determine whether an activity is a game or not:

  1. There are clear and defined goals or outcomes that needed to be achieved.
  2. There are set rules in place to limit how you can go about achieving the goal. By limiting obvious approaches to receiving the goal you are forced to think creatively or strategically.
  3. They must provide feedback telling us how we were progressing or when the game is over. Even if we lost they provide us with feedback so that we knew how close we got so that we are further motivated to get there.
  4. They must be voluntary. No one forced us to play them.

How board games, digital games and even sports fits against these four conditions is quite easy to see. But to see how work fits against these criteria can be a push. No one forces us to work and yet many of us aren’t motivated to the same degree of digital games. Is it because our hour to hour, day to day activities at work poorly fit against these gaming conditions? We go to work voluntarily but commonly the reasoning is ‘to get paid’ or ‘to pay for the mortgage’. It is a fiscal or consumerism motivation that forces up to get out of bed and begrudgingly go off to work? Everyone knows that you should do a job you love but with 70% of American works under engaged or actively dis-engaged it is suggestive that many of us are only there for the pay packet and not because we love it. This is not a simple problem, this is an epidemic.

At work we will usually have goals but they are set at the start of the financial year and they span twelve months. Consider a game where you get given a set of ‘quests’ or objectives once a year, I doubt it would be the type of game you would be interested in.

Feedback on our successes or otherwise is similarly as poorly done at work as it is for the setting of goals. Performance reviews are at worst never done, on average done half yearly and at best quarterly.

Imagine playing a digital game whereby you get recognition of achievement once a year – no one would play it.

The rules at our workplace are ill defined and often built into the culture and the political environment. Jane McGonigal writes in an excellent book on gaming and its relationship to business and life that “Reality is broken”. She believes it so strongly that she named the book after the belief stating that people are flocking to games because the reality that we live in day to day is not sustaining and motivating us to the same extent as digital games. “Compared to games,” she says, “reality is too easy. Games challenge us with voluntary obstacles and help us put our personal strength to better use.”

It isn’t that reality is too easy. It is that the rules are not fixed or that the goals are unachievable against a shifting landscape. Imagine playing a game where when you pressed a button you weren’t quite sure whether the cause and effect were stable. You would press the letter ‘1’ expecting to swing a sword in a fantasy role playing game, for example, and instead would jump in the air. The next time you hit ‘1’ you would wrap a bandage on your arm. We need a world that is stable and consistent, where the rules are known, clear and unchanging, a world where we can win.

How does this apply to software development?

This depends on the framework and approach that you take to craft and deliver your software. As a framework, Agile allows for the greatest support against these gaming conditions. Agile at it’s utter core is a reflective improvement framework. At frequent, regular and defined intervals you inspect and adapt two things – your software and your software delivery process. All of the Agile methods provide a mechanism to reflect, inspect and adapt – in Scrum it is done daily through Burn Down Charts and across iterations through Burn Up Charts, in Kanban it is through Cumulative Flow Diagrams and in eXtreme Programming software craftsmanship is gauged through tools such as code coverage, test case coverage and build statistics. Additionally these methods and ones such as Feature Driven Development inspect the process frequently using techniques such as retrospectives or deltas. Actual output of work is discussed and inspected through Daily Stand-ups, automated testing and end user acceptance testing as each story is rapidly released.

When using an Agile method such as Scrum, work will be broken into commonly two week iterations or sprints. At the start of these iterations there is a clear expectation set of which elements of the software need to be delivered through the stories that are pulled into the iteration. We know that this expectation should be achievable because the amount that was pulled in was derived based upon our previous delivery rate, or in Agile terms, the planned velocity is set to the average velocity achieved of the last three iterations (or simply just the last one). In this respect Scrum highly supports the gaming condition of clear and defined goals or outcomes that need to be achieved, but for other Agile methods it is more of a stretch. In Kanban, for example, the goal moves away from story completion and more towards reducing the time that it takes on average to get a story through the end to end lifecycle of define, design, build, test and deploy.

The rules that are in place for software development are very interesting. Within Scrum some of these rules are in place, in fact Jeff Sutherland and Ken Schwaber define a simile between chess rules and Scrum. The strong rule that an iteration is a fixed time container that should not be disturbed is a very important and key rule, one that should be considered a limitation imposed, and for good reason as it’s intent is to provide a safe, unchanging environment even if it is for only a few weeks. Kanban also has rules that are imposed beyond normal software delivery such as limiting work in progress and allowing change through only one (expedite) at a time.

You could say that a Waterfall development method or process also has goals, rules and feedback but it’s cycles are too long to be considered engaging – the average gamer would be turned off by it’s lack of real time responsiveness.

Whilst all Agile methods will likely have rules, goals and feedback approaches it is the rapidity and formal regularity of these practices that will always create more engaged developers because of the fact that Agile as a method aligns more often with gaming conditions.

Regardless of the Agile method or even software development approach that you choose to use to develop with – all of them are falling pretty behind on a few aspects of the game conditions. Firstly none of them are truly voluntary. Yes you voluntarily do your job but the story or the task that you pick up isn’t chosen by you, nor is the project that you are working on – most developers are assigned to the project. Secondly the rules of politcal culture within the organization are poorly considered. Despite working inside of a container or having some rules in place to handle change – person or process introduced interference will always impede to some extent. Things won’t always go to plan and then more rules are put in place to handle this. Organizational ‘value’ statements, social contracts and Lean’s relentless focus on removing roadblocks are good examples of techniques and methods being applied to resolve this gap.

Can more be done to apply game conditions to the art of software development?

Yes, a lot more. From the way in which we train people, to the way in which we re-enforce desired behaviors or practice compliance we can use gamification techniques more. Gamification is the techniques and mechanics used to solve and engage people through game-like conditions or environment.

The easiest, simplest and most fun gamification technique that you can add are achievements (more on this soon in a future post).

Gamifying the software that you are developing

Along with gamifying the way in which we are working as team we can also keep in the forefront of every software developers, business analyst and product owner’s mind the question “How can I build a product that not only meets the needs the business’ outcomes but also enables the customer to feel like they are playing a game, that there is fun and a sense of achievement built in?”

The marketplace is growing quickly with internet applications that are taking in elements of gaming such as social networking, team-based cooperative play, strategy, role playing, achievements or competitive score boarding. One great example includes Red Critter Tracker which allows you to manage your business’s projects within an in built organizational and project social network engine, achievements and reward. Another great example is Rypple, a people performance management tool, which enables a similar set of gaming features as Red Critter Tracker but focuses more on the person than the project.

It isn’t just the small-medium or start-up companies that are looking into this. Big organizations such as SAP are trying to enter the foray by literally trying to build games into the software.

Authors Note: This article was originally published in the Software Developer’s Journal in January 2012.

Read Full Post »


Get every new post delivered to your Inbox.

Join 920 other followers