techpink

[techpink]

A group of 40 UK-based tech firms has developed a way to help apps and machines communicate in a bid to spur on smart cities and smart homes.

[techpink]

The likes of Union Pacific, GE Power & Water, and ConocoPhillips are turning IoT hype into reality, but they want to do more. Here’s what’s still getting in the way.

[techpink]

NY Times: The Future of Everything

This week I got the chance to team up with Jennifer Daniels at the NY Times to put together this infographic on the future of technology. The piece will be in print this sunday, but it goes online today on the NY Times site “The Upshot.” You can check it out here: future. Thanks to Jennifer Daniels for the great assignment!

[techpink]

The Opportunity for Failure

In every forum where Scrum is discussed, there are the same frequently asked questions: what does a Scrum Master in an established team do? Can a Scrum Master be part of more than one team? Can the Scrum Master be an existing team member or should it be a dedicated role?

There are no one-size fits all answers to these questions, which is why they are also just as frequently poorly answered. The job of a Scrum Master/Mistress/Coach is to minimise the opportunity for failure. All the ceremonies around daily stand-ups, retrospectives and planning meetings are simply a means to that end: the tools of the trade.

This article is the first in a series looking at some of the insights into common place human behaviour that have been highlighted by 50 years of human factors research within the airline industry. The IT industry relies very heavily on people for it's success, just as the airline industry does. Failures in the IT industry are not as public or as catastrophic as an airliner crashing but the basic human behaviours that underly them are the same.

So, what does success look like, for you working on your project or product in your organisation? Is it delivering the required functionality on time or within budget? Perhaps it’s increased sales revenue or a better Google ranking? Maybe it is all about attracting good press? Avoiding bad press? Winning awards? These are the macro successes, what about the micro successes? How do you know when you've had a good day? Or when your colleagues have? The effects of failure might be catastrophic to your product or your organisation but the failures themselves won’t be spectacular and there will likely be more than one - a cascade failure.

It is impossible to foresee everything that could go wrong. Failure is inherent in everything we do and to think that there'll never be failures in our industry is foolish in the extreme. For three reasons: firstly technology is always going to be defined by state of the art; secondly there is always going to be economics involved; and thirdly there are always going to be people involved - the human factor.

Whilst it is generally outside of the scope of a Scrum Master to influence the first two. The third, human behaviour, is not only within the scope of a Scrum Master. It is the reason the role exists. Not only are no two projects and no two sprints the same; no two teams are the same, neither are any two people in those teams the same. Agile is about optimising the productivity of the people you have.

Can a Scrum Master be effective at minimising the opportunity for failure if he or she has another role within the team? No. People are bad at spotting their own mistakes, no matter how skilled and experienced they are. He or she will also have their focus divided, just when clarity is needed most: when the team is under pressure. In the airline industry, no matter how experienced the cockpit crew are, one crew member monitors the instruments and maintain situational awareness whilst the other flies the airplane.

Can a Scrum Master be effective at minimising the opportunity for failure if he or she is part of more than one team? Sure, why not? There are some great Scrum Masters out there who understand the pitfalls of serving multiple teams. The question is will your Scrum Master be effective working with more than one of the teams you have? If you cannot confidently answer yes to that question, then don't divide your Scrum Master's time.

So, what does a Scrum Master do to minimise the opportunity for failure in an established team? They devote more time to the causes of micro failures: factors such as negative training and social and cultural conditioning affect people's problem solving and decision making skills.

For all the sophistication: the quartz-fibre reinforced plastic components; the 530km of wires and cables; the 2.5 million parts; and the 10s of millions of lines of code that make an Airbus 380-800 an engineering marvel. The most complex parts are still the two 1.5kg human brains sat in the heads of the cockpit crew. Success comes from understanding that; Agile is a good start but there is a lot more to learn.

[techpink]

Do you know what your off-shore team’s internal KPIs are?

You’ve educated the client on the benefits of using an Agile approach to deliver the project. You’ve convinced them to sign an Agile contract. You’ve hired the best people you can get locally. You’ve selected the best off-shore partner you can and selected the best people that they can provide. In short, you’ve assembled a stella team of designers, developers and QA people. The client has met the local team. The local team has visited the off-shore team. Everyone knows everyone. You’ve worked hard to foster a relaxed, inclusive culture that promotes personal responsibility and shared ownership. The local team get it but did you check what your off-shore team’s internal KPIs are?

Is the way you are asking your off-shore team to work is at odds with the way your off-shore partner incentivises them? If it is, then all the hard work you've put in to give your project the best possible chance of success is going to be at risk. Ask potential off-shore partners about how their teams are used to working. Ask how their teams expect their performance to be measured. Ask how success is rewarded and how underperformance is penalised. Try and understand your project from an off-shore team's point-of-view. Your project is a team effort, so it is essential that you take the time to understand how to keep all your teams motivated if you want the project to be a success.

[techpink]

If I am selling them something, I genuinely want to solve the problem, not implement agile.  That allows me to be a pragmatic partner with knowledge of agile systems that can benefit my customer.  It breaks down zealotry and keeps me honest.

[techpink]

Wij hebben nu elf argumenten tegen ‘ik heb niets te verbergen’ gegeven, maar er zijn er natuurlijk meer. De komende tijd willen we met jullie hulp dit artikel uitbreiden. Dus: welke argumenten tegen ‘ik heb niets te verbergen’ ken jij nog meer? Of zijn er juist overtuigende argumenten vóór ‘ik heb niets te verbergen’ die je wilt delen?

[techpink]

Working Remotely

Another of the Scrum Master's duties. Almost as good as being there. Unfortunately Google Hangouts runs hot, so not recommended for more than 10 mins unless you like warm hands. 

[techpink]

The Daily Stand-up

As I've written before, I am no fan of the daily stand-up "script": rigid, time-boxed and full of wooden speeches. A coffin in which to bury the conversation that should be taking place.

The rules for the stand-ups I moderate are simple:

everybody in the team has to speak;

conversations have to be on topic, e.g. about the team's current tasks;

we use body language as our guide and move on before people stop paying attention;

no hogging the floor, when the Scrum Master says move on, we move on;

the team talks for as long as there are things to be said and people willing to listen.

  No two stand-ups are the same but they seem to end naturally in under 25 minutes, even on days where a team has faced unexpected problems and have a lot to say.

[techpink]

As Web companies and government agencies analyze ever more information about our lives, it’s tempting to respond by passing new privacy laws or creating mechanisms that pay us for our data. Instead, we need a civic solution, because democracy is at risk.

[techpink]

McDonalds, Mao, Socialism and the Resistance to Scrum

Having read Gabi Steinhardt’s The McDonaldization of the Development Team a couple of days ago, I was about to leave some comments when I saw Ilan Kirschenbaum’s had written a response, The Sovietization of Scrum.

This is my response to their articles. If you’ve come here looking for a rebuttal of either article then you’d best look away now. There is a great deal of merit in both articles and the open minded amongst the Scrum community would do well to take note.

As I’ve said before, Agile is failing miserably to deliver on it’s promises. in my experience, Ilan isn’t way off with his assertion that only “… about 5% of Agile transitions become successful in a reasonable period of time”. So, whilst Scrum is not the last word in Agile any more that Toyota is the last word in cars. Scrum is the Agile brand of choice for most organisations and as such the Scrum community needs to accept responsibility for it’s part in the ongoing failure of Agile to meet expectations.

Frameworks versus Methods

As Ilan correctly points out, Scrum describes itself as framework. The point being that it is explicitly accepted that organisations should fine tune Scrum to meet their own needs.

Sadly when Gabi describes Scrum as a method, he is echoing the reality of the majority of Scrum adoptions/implementations. Namely, slavish attempts to follow what was written in a particular book or taught on a particular course as though Scrum were a method.

This should not be a surprise to anyone. As I've said many times before, in many, if not most, cases Scrum is implemented by inexperienced people working without the benefit of any meaningful support mechanisms. Most of the online Scrum user groups that I encountered have more than a healthy share of self-serving hype and far too many talking heads. People who spout the same dogma in response to almost any question that is asked. All of which only serves to reinforce the idea that Scrum is a method.

Roles versus Titles

Whilst the Sovietization of Scrum makes a nice title, superficially Scrum often appears more Maoist in character. The phrase “Everyone was a private in Mao’s army” comes to mind from somewhere. As does the image of legions of Chinese all dressed the same - the Zhongshan suit.

The lack of other roles in Scrum doesn't mean those are the only roles in an Agile organisation. It just means that Scrum doesn't define any other roles. Not that you would have to look far to find talking heads only to willing to espouse the very opposite. No matter how wrong headed they are.

As a Scrum Master I often have Scrum Master as my job title. A Product Owner might also have Product Owner as his or her job title. However, I've yet to meet anyone who has Scrum Team Member as their job title. Instead, in the role of Scrum Team Member you have designers (Yes, designers are part of the team), developers and testers whose job titles generally reflect their specific skills and experience.

Specialisation versus Generalisation

The trend towards recruiting teams of so called generalising specialists is particularly perverse. It makes sense for everyone on a team to understand everyone else's role. That's just common sense and basic respect. However, understanding someone else's role is not the same as being able to do what they do. Much less being able to do it as well as they can. There is a simple reason why people’s job titles reflect their skills and experience. Professionally that is what we value them for, their Mastery.

It also makes sense to try and limit the number of external dependencies by having independent, self-contained teams with all the relevant skills needed to get the job done. However, trying to achieve this by expecting everyone on the team to be able to do everyone else’s job is at best myopic. 

There are definitely benefits to having some level of cross-skilling but they are limited. The mindsets need to be great UX designers and great QA engineers, for example, are very different. There are rare exceptions but expecting someone to do both roles mostly results in either paying over the odds for those skills or accepting someone with mediocre design skills or mediocre QA skills or both.

Forcing people to generalise leads to a loss of professionalism and a lowering of professional standards. Coming at a time when we already have a highly mobile, global workforce with few, if any, professional standards this the exact opposite of what is needed. So, is it any wonder that organisations are failing to realise the potential productivity benefits of Agile if they take this approach? 

Resistance

Finally I want to add further weight to Ilan suggestion that “Agile is failing because practitioners do not recognize that the resistance has a meaning.” And that “Organizations that relate to this resistance as meaningful data succeed in addressing them, become successful in implementing Agile.”

As a consultant, clients frequently ask me whether or not I have experience of dealing with resistance when implementing Agile. Though they seldom call it resistance. Some clients talk of challenging environments and others are more direct and talk of difficult or opinionated people. What they mean is that they have people who are voicing concerns at what is being proposed and that they are looking for someone who can come in and some how “defeat” this opposition.

My response is always the same. My approach is to listen and to try and understand people’s motivation in voicing their concerns. Occasionally, the resistance is nothing more than a self-serving attempt to maintain the current status quo. Very often this occurs when the client has either over-promoted people or has allowed people to rot in place. The introduction of Agile then threatens to shine an unwelcome light on these people.

Most often, however, what I find is the institutional memory of the organisation being constructive and trying to warn of impending mistakes. This type of resistance often has very little to do with Agile and everything to do with why Agile is being introduced. Examples would include: parachuting in a new development team, which does happens to be Agile, as part of a power struggle between departments; adopting Agile because everyone is, even though you don’t understand it is; or adopting Agile because it’s the only way to hire good developers.

Whatever the source of the resistance, the last thing organisations should be doing is ignoring it.

Conclusion

Agile is not a silver-bullet. There are no one-size, fixes all solutions. Each organisation is as individual as the people who make that organisation what it is.

Organisations seeking to adopt Agile must get smarter about their adoptions. They need to get better at looking beyond the hype and questioning what is right for them. They need to understand what to expect as a return on their investment and what their role is in making the adoption a success.

As Agile practitioners, we must to do a better job of looking at the big picture. Shifting the focus from the seemingly endless naval gazing over how best to run a retrospective and whether paper or magnetic stickies are best. To focus on the whole adoption process, end-to-end. Only by becoming much more professional in our approach and rejecting the snake oil of hype and hyperbole that is currently so prevalent are we going to stop Agile failing.

[techpink]

Resource Based Agile Contracts

In my experience, a "paid for resources” Agile contract model, where the client buys a number of teams for a set number of iterations (sprints) works best. This model works equally well with internal and external clients.

The selling points for the client are:

That they guaranteed a set amount of resource (skills and equipment) over the duration of the contract, with the supplier making good any shortfall in the form of additional iterations.

That they are guaranteed full control over the scope of the work.

The Product Owner is provided by the client and takes responsibility for defining the requirements at a User Story level and for accepting or rejecting each User Story at the end of an iteration.

Though not essential, it helps to define an initial backlog as part of the contract. This makes it easier to strike a balance between the number of teams and the number of iterations. Once the contract is agreed the client is free to update the backlog as they see fit.

It has a low barrier to entry, since the client can understand the contract without needing to become expert in any particular Agile methodology.

  The supplier benefits from their costs being fixed upfront. The client controls the scope but the supplier is only committed to provide the agreed resources. There is no commitment a final deliverable.

I prefer it because it encourages both parties to be agile and it is harder to "game" than models that rely on subjective measure such as Story Points.

[techpink]

Amsterdam life - a long day in the office, followed by a packed commuter train home…

[techpink]

Why Scrum Training Fails To Deliver

I increasingly find myself working with clients who have paid for Scrum training but can't translate that training into real world benefits.

[techpink]

It's always a great feeling when the industry gives you a pat on the back for a job well done.

[techpink]

There's a lot of interesting talk and thinking, going on under the heading of #NoEstimates. I think it's great, and I'm all for it. To do #NoEstimates, people will need some help ...