RUP, Scrum and Kanban

A short blog based on some quick trending from Google.

I wanted some fact based information on the level of interest being shown in the 3 main frameworks that I tend to invest my time in studying in the Agile and Lean arena. Assuming that Google searches are indicative of overall interest (and while they aren't perfect measures, they could be considered indicators...). Trick is to get the terms right...

It would seem that RUP (red) is generating less interest, Kanban (gold) is remaining steady, and Scrum is increasingly popular (blue).

RUP is an interesting one, as fundamentally, RUP can be Agile, and a lot of its concepts and principles are still of value in supporting other implementations e.g. Inception like activities being needed before you start sprinting (the project before the project) and many of the Ivar Jacobsen modelling techniques are still as essential to me today as they were a few years back (although they are not technically hand in hand with RUP). I can only guess that changing fashions and poor implementations (over using the framework predominantly) have result in bad experiences of RUP in the workplace and decreasing interest.

Scrum, despite its problems in implementation, is increasingly common place. I wonder if we are heading toward 'Peak' Scrum, like peak RUP around 2004... The point as which Scrum interest and implementation is at its peak. One issue could be how well Scrum is being implemented, and if Scrum like implementations are leading to less than desirable results, we could start to see a decline in a few years time. I think the ScrumMaster certification has led to widespread awareness of the tool, although 'Mastery' is not in place. Perhaps the Scrum community need to consider raising the bar for certification (which does have value if done right) and consider evolving the training and framework to support successful adoption to ensure continuing success.

Kanban is an interesting one, as for me it has always been an excellent partner to solve many of the issues I encountered with Scrum teams, but its adoption seems to be fairly steady. Perhaps this is due to the resistance to create a marketable KanbanMaster certification? Also, Lean Kanban University is relatively new, so spreading the word will take some time. In my experience, I have observed process advocates interest and time be taken up with getting Scrum 'right', and adopting any new methods of continuous improvement has suffered simply from a lack of effort.

In the ideal world, I'd like to see some of the thinking from Kanban being used to develop what a solid Scrum framework has put in place (especially limited WIP around processes as opposed to sprint and visualising workflow), on a foundation of principles laid out in RUP (Inception activities to get the scope, de-risking the architecture etc...). Easy! There is a tendency to draw battle lines between these techniques, but in reality they should all be considered toolkits, with principles that can be complimentary in improving productivity and removing frustration from software development...

and in the wider context of Agile (red) and Lean (blue)...

The Introverted Analyst

I’m not the most outgoing of personalities and as a Business Analyst, it often seems that the expectation is that I can command and facilitate a room of senior, domain experts who I have never met before and guide this large group to a valuable conclusion using my implicit, natural facilitation skills… unfortunately this is not the case. Despite having some very successful work presentations and public speaking engagements, the fact is that standing in front of a large crowd and feeling the weight of expectation, is a situation I avoid unless absolutely necessary! As the interface between the business and technology, I must be an excellent people person and have charisma oozing from every orifice… shouldn't I?

This expectation is exaggerated, of course, but there is another kind of analyst out there, an introverted analyst like myself, who does not find large workshops a particularly appealing situation (both for running and participating in) and in a large majority of cases I would argue that effectiveness as an analyst (low cost/high value) will be just as good by focusing on different methods of facilitating and interacting with stakeholders… and with new technologies this type of analyst has a new set of tools in their arsenal. I thinks its becoming ok to be an introvert...

The introverted analyst is not necessarily shy but draws energy from being alone and loses energy when in forced social situations... they understand the need to interact with stakeholders, but prefer to limit their exposure to small groups until they feel confident enough that they understand the underlying issues that are present... the context, and can confidently put themselves in their users’ shoes. The risk of looking stupid by not 100% understanding their work is feared, but the introverted analyst needs to recognise that the odd (tactical) stupid question will endear them to their stakeholders and potentially challenge assumptions... like a child exploring a problem, those questions can be key.

The introverted analysts likes to gather new pieces of information, new pieces of the jigsaw and then retreat to their sanctuary (commonly a desk) to methodically work through their project’s problems, where they can go through details with a fine degree of accuracy to ensure that no stone is unturned. They carefully examine options, discarding those that are unrealistic, and when further information is required they go back to individuals or small groups (limiting exposure) to increase their depth of understanding. They prefer less formality, choosing not to create any unnecessary barriers between themselves and their users, and prefer a similarly informal setting in order to drive an open and relaxed relationship with users. Coffee helps...

The work life of the introverted analyst might sound a little laborious but the arguments for workshops are often one of quickly getting everyone together in order to capture some detail on mass. This is especially true if working with project managers who want nothing more than their gant charts to show significant progress. However, arguments for this style of analysis are often ill founded and producing products that deliver benefits and work for real people requires time with individuals.

Despite facilitation training and experience with running meetings, when the size of a group goes over 8 or so people, I find that the value I get as an analyst from my time goes down exponentially as the group size goes up… My experience of workshops of 20 or so people are particularly bad due to either great difficulty in organising busy people to get together at the same time (which is painful enough) and getting the right resources available (an adequate size room etc…). The more useful the stakeholder, the busier they are, and the longer you will have to wait until you can reserve their time; try and get a number of such individuals together, and its not uncommon to wait a few weeks for a 2 hour session whereby a number of issues could scupper the carefully planned session e.g. illness, emergency/exceptional meetings, unexpected personalities and opinion blocking progress etc... When participating in workshops, stakeholders themselves might be introverts and not contribute their views (or have their views unfairly shot down) no matter how valuable they might be, a risk i’d prefer not to take.

Workshops have value if well run and specialist facilitation skills are starting to become independently valuable. Workshops need to be conducted for the right reasons e.g. running through subjects at a high level, and at the right time but I find they are unnecessary for many of the introverted analysts objectives. Workshops will often take them outside of their comfort zone and add unnecessary stress.

There are other ways of being effective; more value can be achieved in less elapsed time by talking through individual’s problems and needs, building relationships, replaying information back to them, and carrying common themes onward to be explored; this can to a degree simulate the innovation that can be achieved in a well run workshop. This personal attention also makes individuals feel part of the project by resolving their issues (regular interaction with a project is a keen way to get a stakeholder on board) and along the way the context from which problems have been defined can become second nature to the analyst. This assurance will breed confidence in an introverted analyst, and give them the required confidence for future interactions. In a relatively short time, a detailed understanding can be gathered across the group where all individuals views have been explored.

In addition, there are a new set of tools available to the introverted analyst to complement their preferred working practices.

Social media offers new opportunities for all Business Analysts, where by they can facilitate large groups with less exposure, and help build larger project/product focussed communities with a relatively low cost. They can radiate out stimulus to a community, and absorb feedback within their comfort zone... This culture and technological enablement is not always in place, so the introverted analyst needs to push for the right culture and setup in order to fully meet their potential.

Social networks are starting become valuable in the workplace, to build virtual communities around projects and themes, and these give the introverted analyst the opportunity to control large groups of people without the same apprehension that they might experience in person. The picture built/outcomes from individual meetings can be published to the entire group, along with a running commentary in the form of micro-blogging, with significant progress being published through blogs... when backed up with email chasing specific issues (through a more familiar/traditional method) and face to face meetings where necessary to re-enforce personal relationships and manage risk, the introverted analysts can find themselves as a community leader and facilitator on an ongoing basis, where information is radiated to them and silos in the community no longer exist... Ambient awareness is spread across the community and engagement levels increase user happiness.

I hope some of these thoughts resonate with your own experiences, and while I’m sure that some of these ideas do not 100% align with you opinions, there is hopefully something useful in here that you can take forward.

And remember, its ok to be an introvert!

Scrum, what's the point?

I recently returned from a trip to the Scrum gathering in Barcelona (#sgbcn on twitter if interested) and I found myself listening to a number of psychological sessions focussed around emotions, human interactions, coaching mentoring, team co-ordination etc... as opposed to Scrum sessions where we would be mentored in how to 'do' Scrum which forced me to ask the question 'What really is the point of doing Scrum or any software process improvement'?

'Improving the way we work' is the fundamental goal here, and this is fairly well publicised by the similarly worded vision of Scrum Alliance. This is an extremely important, as the goals of improved productivity, improved morale etc... are often the fundamentals of why we do Scrum in the first place; it gives us a framework to achieve what many organisations want in there software engineering..

However, we need to ensure Scrum is a means to an end, or more specifically, a means to get on the right path. Scrum is a framework that will guide a team down this path using a prescribed structure and the gaps need to be filled with appropriate coaching and mentoring, guided by organisational principles (don't forget and ensure that other tools such as Kanban, Automated Testing etc... are discussed and integrated where appropriate.

This capability to regularly talk with your team, and dedicate a significant proportion of time to improvement (not just a project catchup!) is key, the most important enabler for me, more important than 'doing' Scrum...

I'd like to see more stories in future and shared lessons of how teams encountered problems, talked it through as a team, and then had success or failure; too often we focus on the former, but I think a 1 hour lesson on failure in introducing new techniques and practise would probably teach me more.

In summary, dedicate enough time to talk about what your doing, where you want to be, what frustrates you and what you'd like to implement as a team. Guide your decisions by principles and goals, and if they are not clear, make them clear. It's great that the Scrum community is talking about these topics, and not being in any way confined or limited by the framework itself.

Reading the Agile Manifeso... Incorrectly

I have decided to contribute a blog based on what I see as a common misunderstanding of the Agile Manifesto's values and perhaps ensure that I myself and reading it correctly!

I see so many people read the value continuums in the manifesto as Agile is against process and tools, or Agile is against following a plan etc... They actively make decisions based on these misinterpretations that lead often to a less disciplined approach, which I believe is essential in Agile; if your delivering high quality software, in an ongoing incremental fashion, discipline is key. As an example Scrum (an Agile framework) includes contract negotiation at it's core with it's sprint planning where the Product Owner gets assurance from the team that a set of work will be delivered in a sprint. However, planning sessions are designed around self-organisation and collaboration so both propositions are included. That is, while contract negotiation is in place, it's not inhibiting collaboration.

The manifesto itself does state something around the lines of "while we value those things on the right, we value things on the left more". I think that this leads to confusion and this or that decisions that are ill informed e.g. As working software is valued over Documentation, ill do some new coding rather than JavaDoc my previous efforts (leading to inefficiencies down the path).

I propose that an easier to understand statement might be "the things on the right should be included in your software development, but not at the detriment to the things on the left".

An example of this is yes, have a defects process and tool in place, it will probably be key, but choose your software wisely. Do not have a poorly accessible defect base that your community can't access, ensure it has dashboards that can support face to face communications in future etc...

Also, put contracts in place, they are often essential for partnerships but do not have any clauses that might inhibit future collaboration between partners.

Hope this helps, or might provoke some discussion.

Cheers, Arran

IBM Innovate 2011

Just arrived back from IBM's Innovate 2011 and have to say it was a great event to be part of.

The organisation of the Event was very polished with several innovations this year. There were plenty of PCs to check, build and print your agenda, RFID tracking so appropriate feedback could be provided, 3D barcodes to scan around the conference (introducing a gaming concept to the conference), superb support for social media (ensuring that everyone could keep in touch), IBM certifications exams included in the ticket and plenty more. I very much enjoyed our trip to Universal Studios, despite the combination of alcohol and roller coasters :-) IBM know how to put on an Event!

My focus this year was Rational Requirements Composer (after already being a big fan/user of RTC) and I'm glad to report a big improvement on last year's integrations and functionality. Im looking forward to testing the web interface's performance (in real world applications) and the ability to do full lifecycle traceability when combined with other tools in the Jazz suite. The CLM setup appeared more seamless (appearing more like 1 tool across disciplines) and RRC was starting to become a great tool for a BA. Minor bugs I encountered during workshops have supposedly been fixed in the CLM 3.01 release due soon. Specifically, I was impressed with the tool's generic and GUI modelling (although it wasn't clear a browser plugin was required at the time), baselining and review capabilities. I've also learnt how to plan releases of requirements sets (collections) and will be interested to see how efficient this is when integrated with RTC; I assume releases are planned in RTC using sizing, requirement collections are then created in RRC, which are then assigned back to the appropriate RTC release? The challenge will be keeping change management as simple as possible across tools.

The progression of DOORS and RRC will be interesting to see (in the 'Next' versions). The OLSC technology had more partner integrations this year, and the Jazz implementation of the OLSC disciplines appear to be turning the IBM vision into a reality. I do however wish IBM were more open about their product roadmaps so that customers aren't left guessing about the products they will be using in the longer term; I, for example, can't see much progression for Req Pro or DXL, and would infer that I should be moving away from these at some point in the medium to long term? I may have missed some key discussions at the conference however, and it must be difficult to manage existing customers while progressing a portfolio of tools. Also, as RRC becomes more powerful within it's web interface, I was left asking what the DOORS thick client will offer capability wise beyond RRC? Will I need both tools?

Overall, congratulations to IBM. They have a great foundation to build on and I'd like to see more of their competitors embrace OSLC in future so that tools can be combined based their pedigree (with less concerns over integrations to other tools). I also would like to see a tester's perspective on how RQM is coming along and it's integrations with the rest of the Jazz suite.

Towards the Perfect Scrum Environment?

Below are my experiences after leading an initiative to create a new collaborative development environment for a department with dozens of Scrum teams. The teams were located on the same site as their customers, but were not immediately co-located.

The existing setup was open plan; it accommodated the engineering department and had advantages regarding cross knowledge sharing and the ability to flex capacity across different areas; these advantages needed to be considered when creating a new solution. There were also several needs that weren't being met for Scrum teams in the existing environment.

Enhancing the Environment

The area was "de-humanizing" due to homogenous nature of each desk. We needed an area that was unique, modern and satisfied the needs of a modern cross-functional developer. Scrum teams had adequate tool support but they started to inhibit interactions between people by storing information away (burndowns, sprint plans). We needed a resolution to this issue e.g. Large screens to publish this 'hidden' information. In addition there was a need for more facilities to display ad-hoc modelling, post-it based planning and support discussions.

Feature Teams and Reducing Silo Mentality

Teams were still working in component teams. Along with a new area, I wanted to encourage the Scrum teams to improve their formation based on features so we could more efficiently produce end to end value. Features enabled colleagues (with diverse software engineering and component knowledge) to be pulled from different engineering 'silos' to innovate and create together.

The focus on features was needed to reduce handoffs in the process and ultimately, lead time in delivery customer value.

Improved Collaboration

Collaboration across teams and stakeholders was primarily supported through tools and the Scrum meetings (where attendance often suffered). Only when developers were lucky enough to book a set of desks next to each other did collaboration amongst people occur face to face.

It was very rare that a Scrum team would work closely with their product owner (beyond the daily standup) and this needed to be addressed to ensure business needs were being communicated. We needed an area that could accommodate developers, customers, support staff etc... together.

In addition, by creating a team identity in an area, solving previous issues and making use of the area a privilege, it was hoped we would improve team motivation.

Solving Meeting Room Scarcity and Unfamiliarity

The standard development environment was not appropriate for product demos, planning sessions etc... Meeting rooms were always required, but there was a lack of availability which caused contention.

Also, equipment when in the meeting rooms was often hard to use due to a lack of familiarity.

The Solution - Overview

After a few months getting suppliers in place, we developed a solution that attempted to solve all of the above issues (to different extents); See crude drawing below...

The area increased capacity within the same footprint, with a 10 desk unique circular arrangement (facing outward) with exit/entrance on 1 side and a 65" TV screen on another side. Users had rolling swivel chairs so that it was easy to collaborate in the central area.

Solution Features

The environment had separating screens on the outer edge that were at head height; this allowed stakeholders to lean over and discuss what work was happening (to not inhibit the knowledge sharing strength of the previous setup) and support innovation. Too high screens can create a claustrophobic environment (essentially a room) while too low screens can lose the sense of 'being a team environment'.

The ability to flex capacity across different areas was in theory impacted but only in scenarios where the division between two border areas would be located over the new environment i.e. Individual desks in the area couldn't be allocated to different border areas as the aim was to co-locate colleagues from areas across the organisation. If the environment was scaled up, workspace managers could simply divide areas up by environment, rather than individual desk spaces; less granular but workable!

The unique workspace demonstrated the willingness for organisational change in support of the software engineering community and stood in stark contrast to the repetitive, non-optimised setup we had previously. The area had modern equipment e.g. larger new monitors on stands that freed up desk space, and satisfied the collaboration needs for Scrum teams.

The TV was a quality brand (to keep the overall brand for the area strong!), and linked up to 2 neighbouring PCs using HDMI so that team sprint and release burndowns could be shared from the development tools. The TV (65") also was excellent for product review demo's and replaced the need for meeting rooms with unfamiliar projectors. In fact, meeting rooms were no longer required for teams utilising the area, reducing contention for others. This also helped increased efficiency in working to/from rooms and booking rooms.

Ad-hoc modelling and post-it based working were facilitated by cramming in as much whiteboard space as possible! We introduced a large whiteboard table that could be scribbled on, small personal whiteboards in corners (to the side of monitors) and a wheel-able whiteboard. Discussions were encouraged through the large, open, central area and the whiteboard table acted as an excellent focal point for colleagues to gather around.

Feature teams began to form for the purpose of using the area and many unique collaborations produced end to end value. The single environment acted as a focal point for business priority work and innovation; if the approach was scaled up however, this focal point 'effect' may not continue. The engineering 'silos' paradigm in place beforehand had definitely been addressed and knowledge sharing across communities was improved.

Co-location of developers and users improved immensely in the area and a lightweight prioritisation and booking process was put in place so utilising the area was not a burden. Face to face collaboration on engineering problems began to occur across users, developers and different areas.

Conclusions and Future Improvements

The area has had overwhelmingly positive feedback (based on the ideas above) and has sparked a series of thoughts about how we could take the next step for improving our environment.

Improvements have included interactive I.T. whiteboards, a slightly smaller capacity (metrics have shown an average occupancy of ~80%), whiteboard desks(!) and more storage capacity for colleague bags/coats.

A key lesson to learn however is that many of the features of the environment can be achieved in any existing setup e.g. Extra effort and time to co-locate with customers, emailing/displaying Sprint burndowns regularly, creating feature based teams and general co-ordination and preparation for the teams work. Also, many of the improvements that had a large impact, were cheap; Notably, the central whiteboard table, monitor stands that attached to side screens etc...

Hope this has given you food for thought in your own organisation!

Socialising Scrum with New Media

Social Media has found it's way into the workplace, and its capacity to facilitate interactions makes it a perfect tool for supporting an agile (and lean) framework like Scrum. I'll talk through my experiences on how Social Media enhances and supports Scrum in a large organisation.

Wiki Tools

Business wide wiki tools are a great way for a Product Owner to publish articles such as a product Vision; not only does a wiki enable a good readership but it also facilitates discussion/collaboration to evolve artefacts into shared artefacts that galvanise colleagues' efforts. For products such as the vision, this is key to ensure the Product Owner has represented the business correctly and that the product will fulfil a real need.

Wikis provide a benchmarking mechanism, a lightweight means to record team documentation and can be found in open source projects (see here).

Social Networking

Social Networking tools are also available through open source projects (see here) and businesses should form strong networks (both internally and externally) to support collaboration and knowledge sharing.

I have found that by having networks for processes e.g. Scrum, roles e.g. Product Owner hierarchies, products e.g. groups who trial beta releases, and disciplines e.g. Agile testing, unique discussions can be created across large organisations that fill in the methodology gaps that Scrum doesn't provide (capturing backlog requirements, estimating etc...) and lessons learnt in one team can be readily shared with another (when the situation fits). I like to call this ambient coaching, and it's a great way to support organisations on their path to both lean and agile. Scrum teams can also view their product's discussions, allowing them to support the Product Owner in developing the backlog.

Micro Blogging

Last but not least, I have recently utilised micro-blogging to facilitate several Scrum teams' interactions. As long as the tools used within Agile teams facilitate interactions between people, they are in line with the Agile mindset e.g. planning tools should not hide away information that then doesn't get discussed by the team.

Micro blogging provides a daily conversation about the living product, improved value to users of released products by reducing support times/interactions, and encourages innovation when new and diverse areas become aware of and discuss your product.

Items submitted are typically published across the organisation (which forms their true value for collaboration), and although the micro-blogs themselves don't carry much information they typically refer to other material and/or lead to follow on meetings and discussions

Inter-team communications can also be improved, especially when teams are not co-located. Micro-blogs create an awareness of what is happening in the team beyond the standup meeting. Microblogs constantly remind colleagues (in an optional manner, the micro-blogs can be ignored) that they are part of a wider team, producing something new as a result of the combined knowledge in that group, I have seen a positive effect on motivation due to this awareness, knowledge that people are not working on tasks that do not affect the wider team. The reduction in waste between handoffs also helps teams meet their sprint commitments e.g. "feature X ready for testing now, get to the gui at this link".

Social Participation

The power of Social Media tools is only realised if both the publishing and retrieval of communications is achieved. It is therefore essential that a means of finding this information is created to enable participation across the organisation e.g. a federation tool that can pull back information based on content and tag information.

Social Media participation also requires that it is accepted by your area/department so that enough time can be devoted to participating in discussions to build on or re-enforce what a colleague has said.

If you don't already utilise (scrum) social media in your organisation I encourage you to experiment, maybe bring it up in your next retrospective?

Improving Scrum Practise with a Gaming Analogy

Im a big fan of analogies for inspecting many things including process tools such as Scrum. Scrum is, in many ways, like a well crafted game. I thought I'd share my thoughts on how gaming concepts could be compared to a Scrum Game and how they could be applied to improve Scrum teams. This blog is part based on theory from the below book, I'd definitely recommend a read if you want some inspiration...




Good games feature a goal, rules, a feedback mechanism and voluntary participation.

The Goal - Achievement unlocked

The goal of any Scrum team should be to turn their product vision into a product reality and deliver value to the business. The vision defines the context, scope, uniqueness and strategy behind the team endeavour, so it's important it's well written, communicated AND believed by stakeholders; compare this to a good computer game...

A game's introduction can take ten minutes, ensuring every player knows the context for their character, the scope of the game (set by the world of the intro - no jumping on mushrooms Mario style in Mortal Kombat), how the game is unique or pushing the boundary (graphically, violently(!) etc...) and sets the game's character on an epic adventure; with this you know the long term (strategic) goals that your character will be trying to achieve.

Game cut scenes constantly re-enforce the gamers purpose in the game and many Scrum teams can learn from this. Often the vision is an artefact produced at the start of a project, but if we are to keep participation and interest high in our teams, the vision should be published, regularly discussed even evolved at the customers discretion much like how a cut scene evolves the game's storyline.

The Rules - Achievement unlocked

A game has rules that the player is introduced to. Scrum defines rules for your team to play their 'game' within (otherwise the game isn't fun); these include daily standups, 3 roles, product backlogs etc...

Scrum allows the team to define their own rules under the inspect and adapt paradigm. I liken this to games where you add rules to your own gameplay in order to progress at a faster rate. If playing in a team (World of Warcraft?) a meeting like the sprint retrospective is required to discuss new improved rules for the team, or roles that will be fulfilled so the team has a better chance of creating something great together.

Game also have mods which can completely alter the core rules of a game to suit the needs of a new set of gamers. This can happen in Scrum, but if the core framework is not being followed it shouldn't be called Scrum (even if it is based on Scrum).

A Feedback Mechanism- Achievement unlocked

A feedback mechanism is essential in games to show a gamer how they are progressing toward the goal of the game. Games have progress bars, points and even fantastic death scenes to show gamers how they are doing.

Scrum satisfies this in the form of sprint and release burndowns, a reminder to the team on how they are progressing against sprint commitments and their next release objectives. Daily stand ups inform the team on how individual tasks are progressing and obstacles (impediments) that are getting in the way of progress.

One thing I have noticed in many Scrum teams is that use of tools stops progress being published to the team who quickly become detached from any notion of it. The tool stores and hides information away, and this can have a detrimental effect on motivation (keep it published and available like a in good game).

Voluntary Participation - Game Over

The one area I find less in Scrum (and elsewhere for that matter) is that teams are not volunteering to be in a team, but are pulled together based on their range of skills, to solve a business problem. They agree to the employment etc... but could a team's motivation be improved if members volunteered to join a team based on reading it's vision.

They would put themselves forward to solve a problem much like a gamer put themselves forward to play a game (normally with huge levels of enthusiasm and dedication). Scrum (as any process tool) requires motivated people, so getting the right frame of mind could make a huge difference to the success of the team.

Hope the analogy provides some insight, I'm sure there are many other comparisons that could be made, some of which might actually be useful.

Improving Innovation within Scrum

Scrum as a process tool, does not naturally lend itself toward innovation; high pressure environments across short iterations, meeting commitments made to the product owner. I thought I would share some of my lessons/experiences/tweaks with teams to encourage Scrum innovation.

The Product Owner

The Product Owner can be a key force for or against Scrum innovation. When the role has communicated a clear understanding of the product vision to the team, this creates a scope/bound that actually encourages innovation by focussing the innovative ‘spirits within’. This structure not only galvanises the team’s efforts, but focuses the innovation efforts in line with the strategy for the product. I would recommend a lightweight vision for all Scrum teams (capturing the needs, features, and unique features of the product). Roman Pichler’s definition of a Vision (not prescribed by Scrum, but a worthy addition) has been particularly useful for me.

The Product Owner must also be sufficiently engaged with their backlog so that they can recognise good innovation items from the team for prioritisation within sprints. Teams should clearly mark innovation items for consideration and ensure the potential benefits of the innovation are communicated; when using user stories, the ‘so that...’ extension becomes important for describing the goals of the innovation.

Setting the right message

Unfortunately, not all Product Owners recognise good innovation, or understand the concept of innovation.  In such cases, innovation tasks are rarely prioritised high enough against the Product Owner’s other backlog items and this can stifle team enthusiasm to contribute innovative ideas.

To combat this, a paradigm needs to be agreed and communicated across the Scrum team that even risky innovations should be prioritised to utilise the intelligence and experience of the team itself to add value to the product; the resulting innovation hits can set your product apart and innovation failures must be tolerated on this road. Scrum teams should celebrate those innovations accepted by the product’s customers as much as those rejected.  A 50% target of successful innovation (against failed innovations) can encourage the right level of risk taking in your product. I would also recommend minimal governance being put in place to ensure that all innovations are in line with the products vision; this could be as lightweight as a published statement of where the innovation fits within the product vision.

If innovation still is proving elusive in your team, I have found a simple yet very effective approach was to agree 10% of the teams time (max) to work on innovation tasks per sprint (taken out of the team’s time during sprint planning). By taking innovation out the prioritisation process, you can free up the team to utilise their talents more efficiently, and motivate them more by allowing them to pursue tasks that interest and challenge them. This could take the form of a 'Freaky Friday', Friday afternoons whereby develops can 'tinker' with their own Scrum innovations.

The Team

On the team themselves, the more diverse a team was, the more innovative their ideas were. They brought different life experiences and skills to problems and this improved conversations across the team, which intern improved their innovations outcomes. Many colleagues had ideas, but it was only when they shared the idea with the team that the idea was improved upon and taken forward.

The teams capacity for fun and their ability to self organise also seemed a key component for innovation. Encourage end-of-sprint outings, night outs etc... In addition, during sprint planning, allow some time for tasks to emerge to solve your team’s commitments and try not to be too concerned about the accuracy of your task estimates (this can be a frustrating process for the team and I’ve often questioned the value of estimates, especially when they have been forced from the team to satisfy the process!).

The Scrum Master

Many teams hold the Scrum Master as the lead/head of the team. I prefer the team to be reporting to each other, the Scrum Master simply ensures the process is followed adequately and serves the team. Teams will put enough pressure on themselves due to sprint commitments and expectations from the Product Owner, the Scrum Master won’t need to crack the whip. Too much pressure will stifle innovation in the team and the product.

Information is king

Scrum of Scrums is a great tool to support innovation by sharing information across organisations/departments and seeing if another team’s work can be applied to your own product. In the same way as the Scrum of Scrums, social media tools can be used to publish information on your product that can encourage others to innovate based on work you have done, or their comments on your product (release announcements, new development that you have prublished etc...) might be the spark for a future sprints innovation work in your own product. Blogs, wikis are common place in today’s workplace and are a great tool for supporting innovation when used effectively (colleagues are given time to participate in the tool’s networks, items are tagged correctly etc..).

Another method that has worked well is to extend product review sessions to other product’s Scrum team members (add them into your stakeholder set). Creating wider networks is a great tool for innovation, and having demo’s of products (not necessarily in the same field as yours) encourages conversations to be started that can lead to great innovations.

Inspect and Adapt

I’d be interest to hear any other methods out there that have improved innovation in your teams or if any of the methods above have worked for you (or not).

The below book was an excellent starting point for me while looking to improve innovation.