Feeds:
Posts
Comments

Archive for the ‘Agile Elsewhere’ Category

Coffee, Cynefin and Visual Management

Posted in Agile, Agile Elsewhere, Cynefin, Visual Management on April 24, 2013 | Leave a Comment »

Disclaimer

Firstly, this is an odd sort of post for what I normally write. It is more a brain dump of a concept or idea I have and not necessarily a well formed one.

The audience was for Dave Snowden or anyone else who considers themselves a Cynefin or complexity thinking specialist.

I openly profess I am not. I am trying to learn and so some of the concepts I have within may be wrong. Please forgive me if I haven’t gotten a concept right. I am here to learn, be challenged/corrected and think differently.

These ideas and thoughts were generated from trying to extend the boundaries of a new movement called “Visual Management”.

blog-coffeeCoffee and Cynefin

Coffee at home

When we make a coffee at home it is a very easy affair. We choose the coffee type from the store (probably your hardest decision), add it to a cup, add sugar if you desire, add boiling water, stir, add milk if desired and Bob is your Uncle.

In terms of complexity of the task it is Simple. The outcome is predictable. The process requires no domain specialisation. In likelihood the home “barista” is also the customer. The quality is…. less than desirable. I know that quality is in the eye of the beholder, but having been privy to some of the worlds top coffee makers and blends and I can say, in my experience, that a Nespresso machine coffee pales to a good barista produced cafe coffee.

Cafe coffee

When we go to a cafe for a coffee the domain expert, the barista, should be able to do a better job of producing a coffee from the commercial quality machines than the average person.

In terms of the complexity of the task it is Complicated. The outcome is still predictable. The process now requires domain specialisation. The barista is no longer the customer. The quality is dependent on the experience of the barista, the process they use, the quality and freshness of the coffee  itself, the roasting process applied, the milk and lastly the quality of the tools (machine, grinder, milk jug).

World Barista Championships

blog-mattLast year my husband was Australia’s 5th top Barista (I am very proud of him). His passion and energy for a good cup of coffee has enabled me to learn a lot about the coffee industry. In order to be a rated barista in both Australia and the world there are competitions that are run each year. These competitions are very arduous and time consuming. This year’s barista champion for Australia spent three months, full time, training for the competition event. In essence, he was sponsored, ie paid for three months, to do nothing but ensure that he was ready for a fifteen minute performance. Judges go through a similarly arduous process. Technical, taste and presentation standards exist and are assessed against.

Baristas at this level are highly passionate, highly educated and use the best tools and equipment that money can buy. To be on top of their game they conduct a lot of experiments. For their twelve coffees in fifteen minutes they would make hundreds of bases, cappuccinos, and try dozens of experiments for their signature drink. Dozens of blends would be tested and a variety of roasting conditions tested. Baristas have to work closely with roasters because, in essence, their coffee is also showcasing the roaster’s ability too. The roaster’s domain experience can greatly affect the barista’s outcome.

All in all, a barista, when they start their journey, would certainly not be able to predict the type of the coffee, the roasting elements, the milk to be used and their signature drink. In terms of complexity of the task it is Complex. The outcome is not predictable. The process requires several domain specialists. Experts are now the customer. The quality is high and graded within clear and defined guidelines.

How does this relate to Visual Management?

When we make a coffee at home there is no value in visually managing this work. Simple work will happen with such predictability and ease that the effort to do visual management would be considered an overhead or waste.

When a coffee is made at a cafe there is some value in visually managing this work – value for both the customer and producer. Complicated work has the simplest of visual management techniques applied – the flow is usually limited to “To do”, “Doing” and “Done”. The variability of items inside of the flow is constrained to a subset of possible conditions,that is, a barista is not going to make you a smoothie or sandwich.

When a coffee is produced for the world barista championships the process to deliver that coffee would benefit from a more complicated visual management system. Complex work has complicated visual management techniques applied – the flow may additionally have a “Wait” column. The variability of items inside the flow are no longer constrained to a subset of possible conditions. Work may now become easily blocked. Work may now have dependencies and relationships to other work items. Work may now need specialization outside of the barista’s capabilities – ie other domain experts are likely required. All of these things can be visually managed. You don’t have to have a visual management zone for doing the world barista championships, but speaking from experience it certainly does help.

Conclusion

For coffee making (and maybe more?):

  • There is a relationship between the complexity category and quality
  • There is a relationship between the complexity category and process specialised relationships required to produce the work value or outcomes
  • There is a relationship between the complexity category and variability of work items within the flow
  • There is a relationship between the complexity category and the predictability of the end outcome (known)
  • The visual management techniques applied sit one category of complexity below the actual work within the system

Read Full Post »

COTS, SaaS and Agile

Posted in Agile, Agile Elsewhere on August 13, 2012 | Leave a Comment »

With the rise of more and more organisations moving towards using Software as a Service (SaaS) and Commercial Off The Shelf (COTS) solutions for their product problems there is a gap in understanding about what Agile can offer in this space.

Most believe that Agile firmly just sits with the actual development of the product and stops there. Today, I will be arguing that there is more and will solely focus on the non product development aspects.

To do this I need to delve a little into the procurement process of choosing a product, but keep in mind that each organisation will have it’s own process. What I will describe is just a method, there will be others, but it is one approach.

So to start let’s go back to basics. You don’t just wake up one day and say “Hey let’s use Product X for our flagship Y!”, unless of course someone high up within your organisation got a free trip to a fab place by a vendor who remains nameless.  You likely have a core need for such a product/service. Maybe your existing system is on green screens. Maybe your business has changed so significantly that you current solution isn’t anywhere close to your needs. Whatever is the reason you need to be clear what the problem is you are solving before looking at what could solve it.

Once you understand your problem think about the needs of the product/service. These are your goals not your requirements.

I believe that it may be at this point in time that you first want to entertain the idea of a COTS/SaaS solution. Normally I believe this would be too early but if you are going down the path of not custom building a solution then you are essence entertaining the idea that you may be dramatically changing your business process model. Now, just as a point, I want to clarify that when I am talking about COTS or SaaS I am not talking about Google docs or GMail, I am talking about software that makes a difference to your business on a day to day basis. It could be a new accounting system or a complete HR package solution. In these instances it is likely that you already have a complicated set of business rules that is embedded to your culture. It is likely that the existing product is so tied to behaviour and process that where one ends and where the other begins is no longer understood.

When you choose to use a COTS or SaaS solution you throw away your business process and use the product/service’s process.

It might be important to you to understand the deviation between your current process versus the product/service’s process via a gap analysis so that you can work out the impact from a re-training perspective, but I believe that it is waste – regardless you will have to retrain or hopefully you will chose a solution that is so intuitive your seven year old could use it.

Next you need to understand your desires for the new product/service. These are your detailed desires – but they should not be thought of as requirements as it is highly unlikely that a single product or service will meet all of your desires.

Categorize your desires into three levels – absolutely critical (showstopper if product doesn’t have), would be elated if it had/did, would be nice if it had/did.

Do these sessions in the same way you would do all of your Agile work – in collaborate teams.

Kick-off your procurement process using the categorized desires as feeder items. Rate the products/services based upon these categorized desires. Naturally you will rate them on other procurement factors such as organisational stability, reputation, service levels, etc.

For the three products/services that score the highest on your ratings invite them into a collaborate workshop (not at the same time, separately). Run this in an Agile way and assess how much they are adaptable to the way you are working. Get them to help you break the desires down into real implementable stories. Estimate the stories with their help. Some stories will cost nothing to implement as it will work out of the box, but a lot of the stories will likely require some element of configuration or data gathering and analysis.  When you are estimating consider any interface implications, configuration, customization (strongly not recommended to do this), data gathering, data analysis, legal checks, policy checks and the number of stakeholders that you might need answers from.

Then with the product/service vendor also break down and estimate stories for training, communications, culture and business process change management, deployments, environments and extent of testing. If the provider will be offsite add in additional costs for communication (an additional 10% in accordance with the Thomas Allen curve).

Prioritise all the stories. You can now compare the plans and costs between each of the vendors with an understanding of the cost of the product/service itself. Chose a provider and continue with your procurement process.

When you start to write all these stories up it should become very obvious that implementing a COTS/SaaS solution isn’t as easy or cheap as expected. In fact, it is highly likely that the product/service itself is just 25% of the overall costs. This is something that the people with the buying power often overlook. It is everyone’s responsibility to make sure the real cost comes out and is understood.

Read Full Post »

Austrian Midrospective

Posted in Agile, Agile Elsewhere, Management on June 13, 2012 | 1 Comment »

I have an hour to kill in the Vienna hotel I am staying at so I thought I would take the opportunity to do a brain dump of what I have seen and done Agile (or technologically related) as a bit of a midrospective:

  • Telstra are evil. I tried to get my phone working with an Austrian SIM card and the phone is hard coded to not allow any other SIM card to work in it. Several internet searches have found that this is due to the way Telstra and Apple setup the phones.
  • Apple is evil. For some reason unbeknown to me apple products don’t work on 95% of WiFi connections here (including my hotel, which was one of the reasons why I choose it). There is nothing worse than watching my hubby surf at ease on his android and me being devoid of any interwebs.
  • Austrian keyboards are weird. The z and y are around the other way. Count how many ‘Y’s there are in this blog. Each one of them I typed a ‘z’ in originally. Many of the special keys are in different spots or work using the right Shift or Alt.
  • I am finding some intriguing parallels between the history of Vienna and Agile. When I get back home I will write a more detailed blog but in essence there is definately a theme of people who were considered revolutionaries, who were incredibly passionate and entreprenurial but were ostricized for most of their lives. How they dealt with it and the ethics that they had I found very inspirational.
  • I have just finished reading Buyology whilst here. Again I will probably blog about it but again found huge parallels to Agile and Lean Startups. If you haven’t read this book then get a copy – it is eye opening and highly educational.

Non Agile related:

  • Surprisingly there is very little sunshine in Summer (it has rained every day)
  • Nothing opens until generally 10am. This would not be an issue if I didn’t wake up at 6am every morning. On the upside most things are open till late at night.
  • I’m sleeping really well. Walking about 7 hours every day will do that for you.
  • I need to buy another memory card. I have been taking about 400 photos per day (and processing them back to 100 at night). Vienna is truly an incredibly beautiful city. If you love jaw dropping architecture every time you walk around a corner then this is a must see destination for you.

Read Full Post »

Agile Governance – The new disinfectant

Posted in Agile, Agile Elsewhere, Governance, Lean Startup, PMOs on June 1, 2012 | 2 Comments »

Following up from my attendance at Agile Australia 2012 I wanted to provide a link to the slides and also a bit more depth of information. Unfortunately a few parts of the panel discussion overran and consequently a few things that I desperately wanted to say were unable to get out.

So firstly, for those that were unable to attend here are the slides:

Agile governance The New Disinfectant
View more PowerPoint from AgileRenee

A write-up of the panel can also be found in the mobile edition of the IT News.

I just want to take the opportunity to get across a few points that I didn’t get a chance to (or were slightly misunderstood):

  • Stop thinking of work as Project vs BAU. When you get to the root of who does the work often it involves the same people due to the shared service nature of organisational structures. You cannot possibly plan by looking at only part of your workload.
  • Everyone will game the system because everyone (rightly or wrongly) perceive governance to be a bad thing. You have to make sure that you consider paths of where people will game the system and either actively encourage it, gather data from it or find a way to shut gaming down in that area. For example, if your governance process categorizes projects that are < $100k as not requiring a certain level of delegation people will split the work down so that it is below $100k. Some organisations would consider this a bad form of gaming the system. I believe that if people can split the work down AND demonstrate benefits also split down then that is an excellent win for the organisation – because splitting it down has just reduced the risk of failure and enabled earlier delivery.
  • Understand prior to transforming your governance model what is broken vs what is working in the model. Understand the wait times, the sink holes, who the deliverables are for and why. For every answer you get apply some critical and root cause thinking to it.
  • Often processes and models get bloated because they are handling odd exceptions – especially exceptions of failed projects. Build a process that works for 80% of circumstances. Let the other 20% be handled by smart people.
  • RUN YOUR AGILE GOVERNANCE TRANSFORMATION AS AN AGILE PROJECT. You don’t have to do everything at once – incrementally deliver it. Once it is “in production” regularly retrospect it.
  • Who owns your governance process/model? Who is allowed to make changes to it? If your answer involves people that never do the activities involved inside of the process then you have just enacted an ivory tower PMO.

Additionally I wanted to talk about where I saw governance going in the future and what were its threats. Thankfully Martin Kearns must have read my mind and tackled part of that topic. But for my record here is my two cents – the biggest problem I see for governance groups going forward are Lean Startups.

People incorrectly think (like I did for a while) that Lean Startups are all about R & D or entreprenural internet corporations. Certainly it is what it was designed for but I have been having visibility that the concept goes wider. For me Lean Startups go back to what Agile really was meant to be about in the early days – delivering very rapidly, ideally each day, having the real customer involved and adapting to change when we find out that we got it wrong. All too often though we are delivering only once every two weeks or worst, several iterations because of perceived lack of “value” until it is 80% there. All too often we still have a Business Analyst as a proxy or a Product Owner that has never talked to a real customer in their life. When people realise that Lean Startups gives us an alternative model to give these back, people will be flocking to it.

Which brings us to the problem of how do you govern a Lean Startup? Think of it in terms of a normal project – usually you have a release date pegged, set budget, a backlog of scope and a clear definition of quality. In a Lean Startup you have a budget set only based upon a date. This date is the date under which your learning stops. If you don’t prove that you are learning then you are unlikely to get another drop of money. Incremental funding is core to Lean Startups – how does that usually work with our fixed capital financial year funds? It means you consider your capital spend a pot of money. Each time you approve another incremental drop of money to a Lean Startup you get your ladel and scoop out a bit of soup. You need to make sure you spend that pot wisely.

So what do Governance groups govern in Lean Startups? They govern learning:

  • Has the team learnt anything about Customer Value since we last saw them?
  • Has the team learnt anything about their planned growth model since we last saw them?
  • Has the team learnt anything about the way in which we can expect a return of investment (revenue)?
  • Are they learning fast enough? How fast are hypotheses being tested?
  • Do the hypotheses make sense given the data?

When I mean learning it doesn’t have to be good news – it just needs to be either validated or invalidated hypotheses.

Most governance models govern scope, time, cost and quality. How many ask the question “Are customers getting value from this product?”. How many organisations are any good at benefits realisation? We spend so much time in governance at getting better at delivering. We need to spend more time getting better at delivering the right thing.

Read Full Post »

Variability with resources and Agile

Posted in Agile, Agile Elsewhere, Agile Practices, Kanban on May 21, 2012 | Leave a Comment »

It all started with a problem with the way we were doing software development. Projects took years with “phases” such as Requirements, Design, Development and System Testing taking six months each. We used to create thud factors where our value was determined by how much the table shook as we laid down our documents that we laboured over for hours on end. There had to be a better way, and as it turns out, there was: Agile.

People often talk about how Agile has failed or not solved anything. But even if Agile had not come along the world of software development would have had to have changed. In a market when speed is important, in a market where delighting the customer has a direct impact on sales, we would have had no other choice then to look at solutions such as continuous deployment, automation and suped-up customer collaboration.

But Agile didn’t solve everything. Some teams found it incredibly draining to apply it to their environment. They described it as trying to fit a square peg into a round hole. They were teams that had large backlogs of work not a “project”, they were not date driven and sometimes they had specialisation. In essence they were operational or maintenance teams. So they sought other approaches that would suit their needs, methods that were more supple to their workflow but still had elements of agility. And they found Kanban.

There are still teams doing work who haven’t had their problems solved. These teams have a different problem again. They have a set date for an outcome to be delivered, high specialisation or domain specific knowledge and variable demand based upon the stage and breakdown of the work.  This doesn’t normally happen in small organisations. This is a problem for large to massive enterprises. Neither textbook Agile nor textbook Kanban fit well in these teams. Primarily this is due to the fact that a stable velocity or lead time cannot be achieved – simply put, the team is too variable. The variability of the team changes based upon the story being delivered.

Let’s take a look at the work for such a team:

  1. Feature A
    Story 1, Priority 8, RPSI (P – Fred Flintstone, S – Barney Rubble, Bam Bam, Ken, R – Bam Bam, I – The boss)
    Story 2, Priority 6, RPSI (P – Fred Flintstone, S – Wilma Flintstone, Betty Rubble, R -,  I – The boss)
    Story 3, Priority 1, RPSI (P – Fred Flintstone, S – , R -, I – Betty Rubble)
  2. Feature B
    Story 4, Priority 2, RPSI (P – Barbie, S – Ken, R – Ken, I – Matel)
    Story 5, Priority 3, RPSI (P – Barbie, S -, R – Ken, I – )
    Story 6, Priority 5 (P – Ken, S – Fred Flintstone, Bam Bam, R – Bam Bam, I – )
    Story 7, Priority 9 (P – Barbie, S -, R – Barbie, I -)
  3. Feature C
    Story 8, Priority 4, RPSI (P – Ken, S – Betty Rubble, R – Betty Rubble, I – Bedrock)
    Story 9, Priority 7, RPSI (P – George Jetson, S – Barbie, Betty Rubble, R – The Thunderbirds, I – )
  4. etc etc

You will notice that there is an attribute attributed to each story that normally isn’t there for Agile work. This is a modified version of a RACI and RAPSI, which is a roles model for processes and activities and a role model for deliverables respectively. The example above predominantely uses the RAPSI model, but some work would benefit from the RACI more. A RAPSI normally stands for “Reviewers”, “Approvers”, “Providers”, “Supporters” and “Informed”. The provider is really the owner of the story, the person accountable. Supporters help the generation by answering questions and providing input. Informed receive the output but for information purposes; sometimes people believe this means they are the end consumers but that is not the intent. The “Approver” has been taken out as it isn’t the intent of an agile process to have heavy approvals – the assumption is reviewed is enough.

Some stories don’t have corresponding names against the roles. That is fine as long as consideration has gone into whether such a person(s) exists and why this story doesn’t require such roles.

It could be argued – when is a team no longer a team? But despite this the work needs to be done and the team does need to collaborate – not on a daily basis possibly, but on a story basis.

Trying to plan for this variability of when certain people are needed in the team could be potentially chaotic. If we tried to work in priority order and ensured that all of the cards were roughly the same size how could we potentially plan out resource needs in advance? The simplest solution is to give a weighting to the RPSI elements. As an example Providers would be ’4′, Reviewers would be ’1′, Supporters would be ’2′ and Informed is ’0′. Lets look at the resource usage for the first five cards in priority:

  • Fred Flintstone 6
  • Barney Rubble 0
  • Wilma Flintstone 0
  • Betty Rubble 3
  • Barbie 8
  • Ken 12
  • Bam Bam 3
  • The Thunderbirds 0
  • The boss 0
  • Matel 0
  • Bedrock 0

So Ken is very heavily focussed at the start of the work, despite being the provider of only two cards. We are hardly using Betty, and not using Barney or Wilma at all. If the team takes the assumption that there is a maximum threshold for a person and that value is 12 for any person for a week then this week is full and no more should be pushed into the weekly plan. So what does this mean for the under-utilised team members? Surely they would go back to doing their other work until the project is ready to pull them?

What has this method done – it has taken into consideration the constraints of the team, the constraints of the story and created a framework to plan week by week without ever having to estimate. It considers the maximum limit of the team and the variability of how they may be involved in a day to day basis. What it doesn’t do too well is drive for efficiency and assumes that lighter or dead time is spent elsewhere.

This approach could be called “VSM” or Variable Systems Method, but someone else took that acronym. It is a different method for a different problem. The Variable Resource Method.

Disclaimer: This is not a method I have been using on software teams, but it is a method I have had to entertain for Agile in the Business. Your weakest link is your busiest resource.

Read Full Post »

Moneyball quotes

Posted in Agile, Agile Elsewhere, Lean Startup, Management, Stoos on April 26, 2012 | Leave a Comment »

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 »

Gamification in Software Development and Agile

Posted in Agile, Agile Elsewhere, Agile Practices, Games on April 5, 2012 | 2 Comments »

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 »

Frequency Foundation and Agile

Posted in Agile, Agile Elsewhere, Scrum on January 23, 2012 | 25 Comments »


Frequency Foundation had its debut launch with its first post back in April 2002 with almost weekly articles ranging from patches that stimulate energy in the weakest parts of your body to multivitamins, the risk of vaccination or of going to hospital, autism causes and even the reversal of aging.

A number of articles and blogs produced by Frequency Foundation refer to “frequencies” that can be used to solve a multitude of ailments ranging from influenza, measles, borne virus, mental illness and even the cancer “germ”. Mercury or fluoride can be eliminated, your hypothalamus can be stimulated or you could even affect bacteria in your stomach associated with the generation of fat. 

Each time these ailments and risks are described visitors are also provided with the opportunity to purchase a frequency for $10US. Alternatively visitors can purchase a $110 subscription to the Frequency Foundation.

These purchased frequencies are provided in PDF which can be re-generated on specific machines. For a more detailed understanding of how the technical elements fit together to “improve the effectiveness of frequency transmission” the “New ABPA Summer Sale” from June 23 2007 goes into considerably more detail.

On March 28 2010 the site moved where similar styles of articles were often output. Frequencies were no longer available for individual purchase but subscribers still had access to changes. In addition the new website provides service of Photo Analysis and ABPA/SC1 Transmission for $200. More detail on what this sort of service is can be found at http://frequencyfoundation.com/forms/PhotoAnalysis.pdf.

Royal Rife and how it is linked to Frequency Foundation

Even in these early days Frequency Foundation was careful to ensure that they had themselves covered with disclaimers:

What you see here may or may not be useful, helpful, or harmful and much of it will not be approved by the FDA. This is a research site and any information is for other researchers to use at their own risk. Consult with your physician for medical advice.

The hint to why such a disclaimer exists is likely due to the association with the technology and theories being used to create/generate these frequencies. The Photo Analysis PDF goes into more detail of this:

Royal Rife identified frequencies for eliminating pathogens using a high powered microscope that could examine living organisms with higher resolution than most microscopes available today. He could directly see frequencies killing pathogens and noticed that exact frequencies were required to generate the effect.

Many people need help identifying pathogen frequencies since Rife’s technology for visualizing living organism is not readily available. Frequency Foundation helps identify these frequencies for a specific individual by analysis of high resolution digital photos.

The Frequency Foundation uses advanced technology originally developed by the Department of Defense for broadcasting the same frequencies remotely using ultra-low frequency bands similar to those used to communicate through the earth to submarines.

Looking at Royal Rife on Wikipedia reveals a different perspective on Royal Rife’s work:

Royal Raymond Rife (May 16, 1888 – August 5, 1971) was an American nventor and early exponent of high-magnification time-lapse cine-micrography. In the 1930s, he claimed that by using a specially designed optical microscope he could observe a number of microbes which were too small to visualize with previously existing technology.Rife also reported that a “beam ray” device of his invention could weaken or destroy the pathogens by energetically exciting destructive resonances in their constituent chemicals.

Rife’s claims could not be independently replicated, and were ultimately discredited by the medical profession in the 1950s. Rife blamed the scientific rejection of his claims on a conspiracy involving the American Medical Association, the Department of Public Health, and other elements of “organized medicine”, which had “brainwashed” potential supporters of his devices.

Wikipedia continues later:

Interest in Rife was revived in the 1980s by author Barry Lynes, who wrote a book about Rife entitled The Cancer Cure That Worked. The book claimed that Rife’s beam ray device could cure cancer, but that all mention of his discoveries was suppressed in the 1930s by a wide-ranging conspiracy headed by the American Medical Association. The American Cancer Society described Lynes’ claims as implausible, noting that the book was written “in a style typical of conspiratorial theorists” and defied any independent verification.

In response to this renewed interest, devices bearing Rife’s name began to be produced and marketed in the 1980s. Such “Rife devices” have figured prominently in a number of cases of health fraud in the U.S., typically centered around the uselessness of the devices and the grandiose claims with which they are marketed. In a 1996 case, the marketers of a “Rife device” claiming to cure numerous diseases including cancer and AIDS were convicted of felony health fraud.The sentencing judge described them as “target[ing] the most vulnerable people, including those suffering from terminal disease” and providing false hope.In 2002 John Bryon Krueger, who operated the “Royal Rife Research Society,” was sentenced to 12 years in prison for his role in a murder and also received a concurrent 30-month sentence for illegally selling Rife devices. In 2009 a U.S. court convicted James Folsom of 26 felony counts for sale of the Rife devices sold as “NatureTronics,” “AstroPulse,” “BioSolutions,” “Energy Wellness,” and “Global Wellness.”

Several deaths have resulted from the use of Rife machines in place of standard medical treatment. In one case, a U.S. court found that the marketer of a Rife device had violated the law and that, as a result of her actions, a cancer patient had ceased chemotherapy and died.In Australia, the use of Rife machines has been blamed for the deaths of cancer patients who might have been cured with conventional therapy.

In 1994, the American Cancer Society reported that Rife machines were being sold in a “pyramid-like, multilevel marketing scheme”. A key component in the marketing of Rife devices has been the claim, initially put forward by Rife himself, that the devices were being suppressed by an establishment conspiracy against cancer “cures”.Although “Rife devices” are not registered by the U.S Food and Drug Administration and have been linked to deaths among cancer sufferers, the Seattle Times reported that over 300 people attended the 2006 Rife International Health Conference in Seattle, where dozens of unregistered devices were sold.

The long winded linkage to Agile

All of the blog entries, both in the old and in the new site, of the Frequency Foundation are done by a single person. This person is an original signatory and co-creator of the Agile Manifesto; the co-founder of the Agile method with 75% of the market share – Scrum. This person is none other than Jeff Sutherland.

Confirming a direct association is not difficult with the Frequency Foundation organisation directly re-routing mail to the Scrum Training Institute at 32 Appleton Street, Somerville, MA. Whois domain registration confirms this again.

Consent forms, submarines and photos

Delving further into some of the information and forms reveals some interesting insights into the quality of such frequency services. The consent form has some particularly interesting statements including:

Because of the lack of FDA or other federal or state government approval of tests, procedures or information provided, I understand that results can only be accepted for their entertainment value.

and “I am here”…

not as a government employee or agent of any type on a mission of entrapment or investigation.

Furthermore, there are references to the technology being used being similar to what submarines used to communicate through the Earth. If you look further into submarine communication the method that is being eluded to is Extremely Low Frequency (ELF) Transmissions which has two bases connected together at a distance of 50 kilometers with their own power source. Due to the complexities of such sites only two actually existed in the world and with the US version now decommissioned the likelihood of such technology actually being used by Frequency Foundation is incredibly implausible (unless they are using the Russian one).

Most of the Frequency Foundation work seems to be based upon research done with microscopes and yet they ask for photo’s to be sent through to allow for remote analysis. Requirements for the photos are equally enlightening:

Take the photos with a tripod, as it doubles the resolution of the image.

Effectiveness is also directly related to the size of the file containing the photo. If you camera will generate a 2MB JPG file, that is 4 times as good as a 500k JPG.

A second digital photo of the whole body from head to toe is critical. If any of your body is out of the photo, pathogens will migrate to that area.

There is no denying, such use of a service can only be considered “entertainment” and at $200US that is a fairly costly form of entertainment.

The blog author’s personal opinion and unanswered questions

Personally I am confused as to why Jeff Sutherland has actually gone to some lengths to separate the two of these organisations. Even his linked in profile has no mention of Frequency Foundation. Is it a concern to him that his relationship with radionics and Royal Rife would impact on his reputation within the Agile community?

I have found only one single person (on multiple sites) who has extolled the virtues of Frequency Foundation. The organisation itself provides no direct references to substantiated scientifically confirmed results – even confirmed in writing if you look at the 6th point on the consent form.

The organisation is still selling Photo Analysis and ABPA Transmissions.

This is not a post to extol or demerit the virtues of Scrum, but if it’s founder is caught up in an environment that denies scientific tests, that is concerned by agents investigating him and has limited technical depth in simplistic things such as photo resolutions then what does that mean for the Scrum community?

I do understand that science theories such as Evolution were discredited by the mainstream population and even officially by the US government for a portion of time but we are talking about a science community that has recently tested and debunked this theory. A theory that has reached the courts and lost several times.

The believer in this theory, Jeff Sutherland, is still trying to sell his $200US solution to anyone desperate for an answer.

Are we being led by a knowledge founder that doesn’t believe in metrics; a leader that doesn’t stop when faced with facts? Does this call into question why Scrum is so slow to adopt change and new concepts?

Are we being led by a knowledge founder that peddles $200US entertainment solutions. Where does “working software” (solutions) fit in here?

How does this fit against the Scrum community’s ethic of openness? How does this fit against “We would rather say, ‘no,’ then make false promises.”

Are there any relationships between Scrum’s method of training and Frequency Foundation?

Is there any link to the Frequency Foundation and the split of  the Scrum Alliance and Scrum.org?

If you feel inclined please leave a response on your thoughts to these questions.

Author’s disclaimer

Opinions presented within this blog represent only the author and not the organisations that they currently or have ever worked for. The opinion of The Agile Revolution is represented within their podcast. 

The author doesn’t mind if you represent the FDA, a government authority, an agent, if you are on a mission or if you found it entertaining (for free).

Read Full Post »

Stoosonians unite!

Posted in Agile, Agile Elsewhere, Leadership, Lean Startup, Management, Motivation on January 15, 2012 | 5 Comments »

The Smithsonian is the world’s largest museum and research complex with hundreds of affiliated museums.

The Stoosonian is much the same but switch up museum with people and thought leaders. It could be the collective noun for people focussed on building such a network focussed on leadership in the same guise that the Agile Alliance crowd marketed the Agile Manifesto.

If you haven’t heard of Stoos then you might have been on holidays and not reading or following the twitter streams in the Agile community. In just one week I heard about it from three separate sources so the community is certainly abuzz. And I hope rightly so.

So what is Stoos? Take a look at their opening statement at http://www.stoosnetwork.org

Reflecting on leadership in organizations today, we find ourselves in a bit of a mess. We see reliance on linear, mechanistic thinking, companies focusing more on stock price than delighting customers, and knowledge workers whose voices are ignored by the bosses who direct them. All these factors are reflected in the current economic crisis, increased inequity, bankruptcies and widespread disillusionment.

There has to be a better way.

In January 2012, a diverse group of twenty one people including senior executives, business strategists, managers, academics, and lean/agile development practitioners from four continents, met in Stoos, Switzerland. We believe that we uncovered some of the common characteristics of that better way.

Stoos SwitzerlandFrom the stoos network page there is a myriad of information that can be found from the closed sessions that were held. A good portion of content has started being posted on LinkedIn and on a variety of blogs and other mediums including #stoos on twitter. In fact, the wide variety of mediums does mean you have the traverse around a bit to gleam everything that is being talked about but without a doubt the social stream is incredibly active.

I spent a few nights taking everything in and having a look around. The hype from colleagues lived up to my initial delve and then I began to test the waters on a few questions that I had. My first concern had been the target Stakeholder list. Now let me start that I am highly impressed that the group took the effort to do this list, debate it and then re-evaluate it. But two things jumped out on that list (and a third now that I have received some responses):

  • The C-section (eg CIOs, CEOs, etc) are rated so low (before and after),
  • First line management is non existent (but maybe that is due to deviations in definition of middle management)
  • Shareholders are rated at 0

The reason why I was concerned in particular about the C-section being so low is that every time I have done an Agile transformation within an organisation it absolutely had to have C-section level buy-in. This wasn’t an optional element. It was critical to success. Without C-section level buy-in teams were left to do Agile in stealth. Sure they worked better than before but there was a upper bound of roadblocks that endlessly re-0ccured and never got addressed because there was no organisational focus on being Agile. Culture of the team subtly changed but without C-section buy-in the culture of the organisation would never change.

This is critical to not miss. Agile, to get the benefit, requires cultural transformation. The Leadership problem is no different – in fact it is more often then not Leadership that drives culture. I’m not just talking about first line managers but also middle managers, CIOs and CEOs.

I then did a deep dive at the problem analysis done. The Stoos problem mind mapAgain I want to take a moment and congratulate the Stoos team on the job they did on generating this starting diagram. I would imagine they spent a few hours on this and as a starting map I think it covers most of the key points. To get it past 80/20 right it would have likely taken the whole two days.

If you take a look at the top two (not necessarily by priority) root causes you see shareholders and C-section management as the cause.

So my concern is that without doing something to address those two root causes that all this effort might be in vain.

Side note: would love to see the 5 whys applied to the root causes because they aren’t base root – eg Why are leadership skills missing in today’s managers?

Now I posed the question of C-section being non targeted in the twitter stream and was given a couple of nice links which is great information and a step in the right direction but again isn’t the root cause. The root cause as in the article is lack of education – and who do we need to educate? – the C-section, shareholders, and future to-be C-managers. Which is why I am happy that educators are high on the target audience. So there is hope, but maybe not in my lifetime.

What I love about the Stoos community thus far:

  • They are responsive, they are listening and they have some beautifully deep thinkers in there. A few of the questions that popped up in my mind today whilst I was a road-trip I was amazed to have found others ask and have had answers/responses to.
  • There is an appreciation that the command and control culture is thousands of years old – this is a very deeply embedded behavioural human trait. I am curious if it is neurologically driven somehow.
  • There is an appreciation that we actually have the answers on how to lead – it is just that for some reason it is not disseminating as expected. This is where I think some deep thinking root cause analysis needs to be directed towards.

As a test I asked a friend of mine who leads a team of ten about their leadership.

Do you think you are a leader or a manager?
A little of both. More detail then given.

How do you think your team perceives you – more as a leader or a manager?
Probably a manager.

Why did you go into management as a field?
For the money.

Not because you enjoy working with people?
No. I was smart, it was expected of me to progress that way.

How much time do you spend learning of new leadership and management techniques?
None. I have no time for that sort of stuff. I am too busy. 

So if you weren’t so busy you would spend some time learning how to be a better leader/manager?
Probably not. 

I could have continued going on to find the root cause but at that time my friend was starting to get the picture that I wasn’t playing nicely. Getting honest answers on this is going to be hard but we need to get some broad understanding (ie real metrics lean start-up style) to make sure we are going to make a dent in this massive global problem.

So lastly I want to say thank-you to the Stoos group for having the guts to tackle this and to make a great start on it. I am pleased that the group has such a diverse set of thinkers but would love to see a few other thoughtleaders included in the list – my pick would be someone who represents motivation (eg Dan Pink), someone for crowdscourcing (eg Dan Tapscott) and someone from the field of Neuroscience (to be honest Peter Burrows wouldn’t be so bad as he conceptually understands Agile and more importantly has some interesting team dynamic theories).

Keep it up and don’t take this blog as a big rant of criticism – the good certainly way outweighs the bad.

Read Full Post »

Agile Manifesto take 2

Posted in Agile, Agile Elsewhere, Kanban on August 20, 2011 | 2 Comments »

What would 17 peeps do in a Jacuzzi you think?Ten years ago some smart guys got together to find what they had in common despite being to some extent competitors to each other. I like to think that whilst at The Lodge at Snowbird ski resort that they jumped into an extra large jacuzzi and sorted their differences to find their passions that aligned.

At the end of their bubble bath they had reached enlightenment and defined the Agile Manifesto and named themselves the Agile Alliance.

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

I was greatly anticipating hearing where the Agile Alliance group would say as part of their 10th anniversary re-union at Agile 2011 Salt Lake City. Admittedly my information was limited to second person discovery or tweets and I didn’t expect anything dramatic, but some contention or even one person standing up and having the courage to say ‘Hey maybe we could have fixed the wording a little to suit audiences other than software developers’ would have been good.

So for a lack of seventeen people taking the stance that there could be an element of imperfection (or dare I say it taking an iterative focus to constantly refine it) then I am going to give it a crack:

Manifesto for Agile Solution Delivery

We are uncovering better ways of delivering solutions and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working solutions over comprehensive documentation and meetings
Customer and team collaboration over SLAs, KPIs and contract negotiation
Responding to change over following a plan

Constantly reflecting and improving the way we work over following a process without understanding why

That is, while there is value in the items on the right, we value the items on the left more.

Why the changes?

  • Agile isn’t just for software development. It’s application has now broadened to include other areas of IT including hardware, services, process improvement and for a large number of people it is being applied outside of IT into other domains. I can appreciate its origins, but some of these origins are in Lean and blending Lean and Agile together has given us a really strong framework.
  • This framework has broadened the practices, techniques and tools that we use to implement Agile. Each month it alters a little and I think that is a great thing. I don’t see Lean broadening itself to take on other approaches. In some way it risks diluting the original purpose of Agile. In some way it can be debated whether this dilution means we are following Agile or something else altogether. For me, it is about bringing the right tools for the problem. I don’t care what it is called, but for the moment let’s stick with Agile being an umbrella term. The new added manifesto item for me is this constant refinement – not just of Agile itself but of how we apply Agile. I know it isn’t worded right, but the concept I am trying to get across is that we are dealing with Complex Systems and thus the only way to improve is through a reflective improvement framework. Alistair Cockburn said it best with his Oath of Non-Allegiance - it’s about finding the best solution for the current situation.
  • Team collaboration is just as important as customer collaboration, but I guess this could be covered off by the Individuals and interactions over processes and tools statement.
  • Only a small portion of the development community have any relationship or reference to a contract, so I expanded it to include SLAs and KPIs/KRAs
  • Change of wording for software -> solutions
  • Change of wording for development -> delivery
  • Addition of something about meetings. All too often I see teams complain about Agile because of the sheer number of meetings with perceived low value. Collaboration is important but not at the risk of reaching consensus perfection. Get your 80% value from the meeting and then shut it down.

Should the Agile Alliance take a step to re-write the Agile Manifesto?

If you are interested in other variants take a parody focus of the Manifesto for Half-Arsed Software Development or Manifesto for Software Craftsmanship.

P.S. Sorry for the delay in a post. Computer failure, followed by a cold, followed by a brief holiday, followed by many podcasts for Agile 2011 are poor excuses but I am using them.

Read Full Post »

Older Posts »

Follow

Get every new post delivered to your Inbox.

Join 604 other followers