Fail Fast, Fail Small to avoid Failing Big and Failing Slow #BusinessAgility

You would think by this late stage in the life of Agile and Agility that the concepts would be well embedded in organisational transformation, people assessments and processes. From my experience I’ve never seen Agile actually fail, I seen people pervert its meaning and make up their own versions then blame a framework for personal incompetence. Likewise I’ve not seen DevOps fail either.

There is something at the heart of business that hates the idea of being associated with failure in European culture. It’s not even logical as Socrates proposed a logical form that constantly tested (hence willingness even a desire to fail to find truth) by debate. The Socratic method is a form of cooperative argumentative dialogue between individuals, based on asking and answering questions to stimulate critical thinking and to draw out ideas and underlying presumptions. Concern around failure relies on deep seated fears around not being able to prove worth and conversely the chance that any hint of failure transfers on to the person rather than the thing.

“Fail Fast, fail Small to avoid failing Big and failing Slow”

Fail Fast in organisational transformation, people assessments and processes

If your going to really take this on you should start at the beginning, planning the programme and making the case. Instead of getting some expensive consultants who want to try something in your company (no many how many times they say they have done it elsewhere) get one or two Agile DevOps strategists (these are certified Scrum practitioners) and get 60/100 of your staff from all levels into a room and do a two day hackathon. Will they hack your company, no they will hack the problem and hidden problems to define the ‘Problem Statement’ on day 1, on day 2 they will map out all the moving part to define the scope. Could it fail, absolutely, could it save 12 months of 6 consultants on £2500 a day absolutely.

Start at the beginning with people too, most management exists either to direct work (which should be automated or manage people who are not trusted) or to circumvent freakishly hard processes to get the most simple things done. If your planning on changing the emphasis in your company from hierarchy to teams and outcomes, you must offer the incumbents a way to revalidate themselves or they will actively seeking to cripple or pervert the programme to suit themselves. Quickly test the water with an alternative career path based on knowledge not prestige or headcount. See how many people will sign up to not having to manage people, be appreciated for their knowledge and be paid them same as now? You may be surprised.

Processes in this scenario begin to take care of themselves but its always go to run some ‘what if’ or ‘unhappy path’ testing too, to create checks and balances around change.

Fail Small in organisational transformation, people assessments and processes

When you have worked out your plan, don’t enact the whole thing choose a critical path (if thats what fits with your company targets), a happy path for customers or a low risk path and do the MVE, that’s minimum viable experience to success. Viability in transformation is really important and often missed, viability is the whole not the part in transformation.

“Don’t make a door handle that doesn’t unlock the door”

You’d think that would be impossible but the MVP of a door handle is a door handle that looks like a handle making the mechanism to open a door is the MVE. Often in a transformation people focus on rebranding, a new and more exclusive hierarchy, but that is just the look of things, making it work means that the people and machines that customers and colleagues interact with it, do so with higher quality, are quicker, traceable, with measurable delivery.

Fail Big and Slow

This is pretty much a description of most businesses in their current state though many would not see themselves that way. My first question to any organisation is ‘where do you get your money from’, ‘why do you get it’, ‘are there anythings expected of you to continue to get it’. Weather your a corporation, government organisation or corner shop, getting the money to operate and pay people is part of the clear line around purpose and value. When you have clarity on those compare your ideals with where you are now, are you failing steadily, but very slowly? If the answer is yes, you need help. Contact us here

Tagged : / / / / / / /

#Innova8 combining #designthinking #servicedesign and #userexperience #customer validated services and products

Innova8™ combines design thinking, service design and user experience within an 8 hour process, that takes business issues and delivers customer validated solutions and prototypes.

Innova8™ is a process that fits into Agile and Lean, facilitating DevOps Organisational Design and brings the business closer to their customers through a lens of digital technology and customer validated interactive behaviours.

Design Thinking should never be used to define software, it’s the wrong method. It will create software that only executives want to use, not customers

Design Thinking is a great method to distil the strategic needs of an organisation defining ‘How do we make money’ and ‘What are our services’. Service Design defines ‘How a service works’ and the interrelated model to setup, deliver and manage services, defining customer touchpoints, potential communication routes, digital technologies and key interaction models for a defined service in a blueprint. UX engages directly with customers to deliver the detailed product blueprint for communication routes, digital technologies and their individual key interaction models.

Paradigm Interactions Inc. owns the worldwide rights to the innovation process Innova8™ developed by Karl Smith. The process outline (without critical details) was first published online in 2001. Innova8™ is a unique innovation technique that mashes counterintelligence techniques with human-centered design methods, clients, customers and creative people.

Innova8™ 86681840 in the United States of America

International Class
042 – Scientific and technological services and research and design relating thereto; industrial analysis and research services; design and development of computer hardware and software; legal services.

The process enables clients or consultancies to establish rapid innovation labs to an 8-hour process, where real innovation that meets customers and business needs can be done in hours rather than months or years.

Some completed projects

  • Innova8™ with Deutsche Bank – No film
  • Innova8™ with The Roundhouse – No film
  • Innova8™ with Vodafone UK – No film
  • Innova8™ with Bank of Moscow – No film
  • Innova8™ with Bradford College – No film
  • Innova8™ with Pearson Education – No film
  • Innova8™ with Oxford University Press – No film
  • Innova8™ with Oxfam UK – No film
  • Innova8™ with Zoopla Property Group – No film
  • Innova8™ to launch Accenture Financial Services Innovation

  • Innova8™ to launch Wipro Digital Company

It is worth noting that design thinking used to be called UX strategy, service design was part of UX too, the fact that these have been reinvented as new things is concerning for clients costs as in 2010 when you request UX you could get all three types of skills in one UX person. In the case of senior UX people clients still can. Innova8™ does not rely on these more experience people, but can be done through a group of people with various skills and backgrounds.

For more information please contact the Author: Karl Smith https://www.linkedin.com/in/karlsmith2/ or visit http://paradigm-interactions.com/paradigms/innova8/

Tagged : / / / / / / / /

#UX and #Development cannot exist in the same #Agile workstream

“UX and Development cannot exist in the same Agile workstream” might sound like an outlandish claim but if you fully understand, it’s obvious. Forcing things to work as with the picture above is not a good idea.

Can UX be Agile yes, of course in so far that all the effort and artefacts required to deliver UX can exist in an Agile UX workstream.

UX includes user research, user requirement, KPI’s, system-wide taskflows, concepts, concept testing, persona definition, user roles, user journeys, usability and accessibility standards, sitemaps, key pathway wireframes.

Development can also be Agile, but not all of it, infrastructure and front end need to be in separate workstreams.

The simple way to express this is to talk through backlog items in a greenfield system;

The user can login…..

  • UX will take days
  • Front end will take weeks
  • Back end will take months

The problem is not size it’s Trajectory and Dependencies;

  • UX = T small, understood activity : D access to target audience to validate success and failure paths
  • Fe = T mid, may need investigation : D access to dummy credentials store
  • Be = T long, will require architecture to respond to scalability and bandwidth changes : D modelling data, server set up, pen testing

Once there is a fuller understanding of these very different aspects of defining, designing, building and deploying it’s become clear that these areas have common points but cannot be run together as and Agile project and to tell client’s that they are is not true.

Agilists don’t call this blind behaviour Agile, we call it Fragile (When Agile becomes Fragile nobody Wins) as we know it will shatter at the first problem.

Tagged : / / / / / / / / / /

#Agile #User #stories is a #UX #method

User stories is another name for a Cognitive Walkthrough

I have been involved in Agile for a very long time, mainly because it uses methods from the human computer interaction scientific process (CHI/HCI).

I’m surprise no one else has blogged about the use of CHI/HCI processes in Agile before, but though I should say something as I keep getting told that it’s interesting how many CHI/HCI people have embraced Agile. In fact it’s the other way around

Agile has imply appropriated UX techniques that have new Agile names

The main one is User Stories; they are in fact a reuse of the Cognitive Walkthrough, but I’ll let you draw your own conclusion.

Cognitive Walkthrough

Cognitive Walkthrough is a method utilised to express how the system works from a user perspective it exposes potential usability failures and defines happy and unhappy pathways

The method starts with a task analysis that specifies the sequence of steps or actions required by a user to accomplish a specified task. The system response to each action is noted. The designers and developers of the software then walk through the steps as a group this enables an agreed view. They ask themselves a set of defined questions at each step to determine all the potential outcomes. Afterwards a report of potential issues is compiled and the project team has a clear focus on the various user pathways including happy paths, risky paths, error paths and failure paths.

User Stories

User Stories are a quick method to determine the who, the what and the why of a business requirement and are produced in a narrative format as if a user was walking through their use of an interactive system

User stores are written at two levels Epic Stories that define groups of functionality (registration) and User Stories that define a single piece of functionality (sign in).

User stories are written by the product owner (an Agile tile for stakeholder or product manager) a user experience architect or a business project manager (not a scrum master) or the development team when they break down stories that are too large (these are then confirmed by the product owner).

The method starts with defining the Epic stories, then breaking these down into smaller stories that relate to an encapsulated (self standing) component. In design and development these stories can be parcelled to the various specialisations including user research (end user validation, How It Works), visual design, user experience design, back-end development (feature and service delivery), security and front end development. These stories will have their interlinks (to other components) stubbed out until those stories are built and can be integrated.

Agile + CHI/HCI = User Centred Requirements, Human Centered Design and Human Centered Development.

They are not exactly the same but the essential method is,

  1. think like a user
  2. describe what you can do
  3. build the system that enables a user to complete a task or aquire a feature

 

Author Links

Tagged : / / / / / / / / / / / / / / / / / / /

#Blended #program #management #Prince and #Agile methods Part 1

Blended Program Management

I have been involved in project and program management since 1989 across various sectors and more recently have been focused in banking and finance.

I have experience in Prince and Agile methodologies and will expand on the blending of these two methods through the use of user stories (a user experience method) and the positive relationship between waterfall and iteration components in the following parts of this post.

Simply put (before getting into the detail) Prince and Agile = Delivery and in Banking and Finance they can give startling results.

This will not be a shock to many people but I’m not going to be describing the what, but the how.

I have managed some highly complex projects that would have failed if they had been run in Prince or Agile alone.

The clear advantage of blended management processes is that;

the project becomes team centric and affords an environment where success in common and that value is attributed to the correct people

Tagged : / / / / / / / / / / / / / /

Save 35% ££ on banking change, requirements gathering should take no more than six months

Best practice, puting the missing part in a puzzle
Best practice, puting the missing part in a puzzle

Requirements gathering in Banking change programs are over detailed, over long and for the most part undeliverable.

There is and has been a huge requirement for change in British banking for several years as senior bankers have sought to lever the capabilities of technology and distributed workforces. This has in turn a great opportunity for IT consultancies to enforce their business models on the banks and make huge amounts of money without delivering anything. This has of course not gone unnoticed and forced many banks to increase their internal IT teams, but the problem remains, as the overall strategy is wrong.

The current strategy for business change requirements gathering is to fully understand the current problem with the assistance of subject matter experts (SME’s) and then defined the end state with the internal client. There are several major problems with this approach;

  • Fully understanding the problem is almost endless in Banking
  • Using SME assumes they really are experts which for the most part they are not
  • That the internal client can see the future of their business
  • That the same consultants will carry the project all the way through

The solution to this problem is a new strategy, in fact an Agile based one;

  • Defining 6 to 10 features of the new system at a high level
  • Involving the enterprise architects to see what has to be new, legacy or adapted
  • Launch the development team during the definition phase
  • Detail the features and get time costs from the designers and developers (not the PM or delivery manager)

Doing the above will change the relationship between requirements and delivery making requirements a service to the delivery of the project rather than an impossible set of promises made by people who will never have to keep them.

The 35% savings is probably low it’s just the 14 months and 35% of a budget wasted on an investment banking project that were eventually discarded. I’m considering a new concept in banking requirements gathering, value for money, is anyone interested?

You can contact me on karl@karl-smith.com

Tagged : / / / / / / / / / / / / / /

#Banking #Change #Management through #Human #Centred #Design #HCD

There has been massive change management taking place across all sectors of British banking over the last three years. Much of this is driven by buy outs and mergers, some by efficiencies and a little more recently through questioning the nature and controls around risk management.

However simply changing the owner has caused major problems in these banks as their competitive advantage and therefore their value has been an amalgam of very different skilled people, internal processes and market penetration from the bank or group buying them. These internal processes have often evolved in a highly organic method through acquisition and proven delivery often driven by individual people. However once this people based relationship is broken and these processes are exposed to a wider audience they pose serious questions in relation to risk management, value and the continuance of revenue flow.

The standard process applied has been to pass these processes over at division level to change program managers, at department level to business analysts to define the scope of the current structure. After definition many of these process based activities are passed over to information technology to resolve. I remember being taught at University (Napier, Edinburgh) that technology should never be used as a substitute to sound business process; however this technology determinant does not seem to have been passed on to banking business people. While not the best starting point, people who work in technology do tend to ask the right questions, to define epic requirements, even when it’s unpopular with the business.

Information technology analysts take these epic requirements and define an A to Z system ‘what it does’. However to get the B to Y user requirements (or stories), a user centred design analyst, ux research and designer spends time with the users to define ‘how it works’. This may seem obvious to digital practitioners outside banking, but it’s a revelation to those inside banking and banking technology, that users who normally find ways around poor software are able to define the requirements that turn a useful application into a killer application.

This is not really the end, more a beginning, if other sectors can learn from banking, that users (not stakeholders, usually no longer active users) can determine the overall success of software. And that user centred design (UCD) can assure and amplify competitive advantage if underwritten by skilled practitioners, then the possibility of success is significantly raised in all software and change programs.

Author Links

Tagged : / / / / / / / / / / / / / / / / /

When #Agile becomes #Fragile nobody #Wins

I have been an Agile practitioner a very long time, in fact as an Instructional Designer I was very excited when Agile was created based upon Computer Human Interaction methods and thinking. As one complete fully applied process Agile is astoundingly effective at bringing together all the best capabilities within a project team and totally removing the hierarchical and often power crazed notion of single point leadership.

Agile and Structured Business

Agile, however does not remove the need for formal and structured Program Management that interfaces with and supports a more formal set of business processes. I can only say this from experience, if you have managed to get the board, finance, operations or other parts of the business to operate in a true Agile fashion please tell us how you did it. I have now worked on a programme that has attempted this, I’d say we got 40% of what we were looking for. That has to be a caveat thought it has to be true Agile, not some invention of yours that you are calling Agile to cover the fact you have made up your own process.

The Agile Team

When I’m working on an Agile project it’s really important the team is complete during all aspects of the Agile process, at enterprise level that includes;

  • User Experience Researchers and Consultants – SM*
  • Visual Designers
  • Business Analysts – SM*
  • UI Developers – SM*
  • Backend Developers
  • Security Consultants
  • Database Administrators
  • Enterprise Architects – SM*
  • Testing Team

From experience the ScrumMaster – SM* can come from any of these groups. The Scrum Master is an active participant in the project and is not an administration or leadership role. The team leads itself with support from the ScrumMaster. The ScrumMaster also produces non partisan solutions along with everyone else. If the final solution is what the ScrumMaster wanted you have not done an Agile project, just an ego trip for the person with the title ScrumMaster, who is in fact, just an old school project manager.

Agile Planning Poker is a team Exercise

Whenever I join an Agile project my first question to the team is when did you play Planning Poker. This is my first clear indication of how Agile the Agile project really is, I hear answers like “what’s that” or “the planners played it, I think” and I know from that we are all doomed!

You might think that’s a radical response, but Planning Poker is the foundation of Agile, its the point at which the Agile team;

  • Discovers the complexities, depth and breath of the project.
  • They get an indication of it’s relevance within a program.
  • They start to piece together the skills and knowledge of their teammates.
  • They begin to establish team thinking.
  • They start to understand their relative strengths and role.

It is integral to an Agile project that the team as a whole own the project, everyone is responsible for every aspect, no one throws anything over a wall to another discipline they are all in it together.

Playing Planning Poker can be done is several ways I still opt for the original method with playing cards. Your looking for an assessment of complexity from the perspective of the highly skilled persons technical knowledge. With such a diverse group of people it is rare the get agreement, however doing the first round together is important to expose Trajectory issues.

If you do the first round with everyone in you will get wildly different scores between User Experience, UI Development, Backend Development, Database Administrators and Enterprise Architecture. This is because a simple requirement in one discipline many be extraordinarily complex or even impossible in another area due to existing structures, legacy constraints, timelines or even regulation.

After the first round I separate the groups to find out what they think their score will be. I focus on four key groups who’s timelines can be vastly different and if just pushed together usually causes the project to fail or worse never succeed (we should as a culture look for ways to help people feel successful, happy appreciated people work better and harder) as it was intended, creating a desire to move the goal posts.

  • UX includes research, conceptual design and customer testing (absolutely no high fidelity design work is done in UX)
  • UI includes visual design and front-end coding
  • BE includes backend developers, security consultants, database administrators and testing team
  • A is for enterprise architects

Also remember when you get to your sprint planning the reasons for these different responses and be careful to make four sets of cards, working out where the work-stream touch-points will be so they can feed into each other at the right time.

Agile Planning Card
Agile Planning Card

I know plenty of people do this differently save money, save time but produce pretty products that people don’t want to use of can’t use, because the MVP is not viable or it never gets launched in time because the enterprise architect were were involved too late to get regulatory and legal to review and approve the product.

Summary

I’m not going to do an exhaustive review of Agile here, but the fundamental thing is you can have a Stand Up or a Sit Down to your hearts content but it won’t be Agile. You need to get the basics right play Planning Poker with the entire team to create cohesion, then specialise the Poke to to get viable information. Only when everyone’s skill and experience is involved can you be truly Agile and avoid the awful experience of a Fragile project. Fragile projects are not Agile ones except in name only the process has not been fully applied, easy to spot with people who have created their own version of Agile meaning, Not Agile.

To date my best enactment of Agile was with a .NET team, they were 3 weeks in when I joined, the team was not complete, the requirements were 50% of an A4 page and the budget £1,000,000 on this part of the development alone. The first thing I did was Planning Poker with the available team, around 40% of the final team. I found were dramatically understaffed to deliver in 6 weeks time. I went to the CFO and got a budget release of the extra 50% more staff and a 3 week reprieve to get them before the official start. From official start to completion of a .NET Business Intelligence Toolset working on a 5 day sprint plan was exactly 6 weeks to the completed version 1.0 of the software.

Karl Smith – Scrum Alliance

Tagged : / / /