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, 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)...


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


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.