There are many other books that I want to mention, but I want to try and keep the list reasonable and focused. Here, then, are some of my other favorites that are worth reading when you need more specific information.
I do want to mention my own books, briefly, though. I publish books through LeanPub, which I highly recommend if you want to publish your own book. Most of these are short and focused, but all of them are worth their weight in gold.
If you want an esoteric look into the language, from a writing perspective that fits better in academia while still trying to provide real-world relevancy, go ahead and pick it up.
There are so many more books that could be mentioned, and I would love to continue doing so… but I also want to keep this list reasonable.
Here's the short answer:
Both are reflective and adaptive. Kanban is focused on limiting work in progress whereas Scrum limits the time you can spend on a problem before you have to produce a result. If your product were a car, Scrum would be saying check your oil and tire pressure every month, and Kanban would be the warning lights on the dashboard that turn red when something is amiss. Both the maintenance intervals and the warning lights have value, and it would be silly to ignore either one.
Here's the long answer:
If I remember David Anderson's Kanban course correctly: Every sentence has a subject, a verb, and an elbow directed towards Scrum! OK, I exaggerate slightly ;-) Let's look at this more closely...
What is Kanban?The purpose of Kanban is to create a culture of continuous improvement aka a "Kai-Zen Culture". Kanban does not define a destination, but rather strives to create a culture that is willing to improve.
This essence of Kanban can be summed up in three steps:
- Don't change anything. Change causes fear. Respect people and their roles. So leave existing roles and processes unchanged.
- Agree to get better.
- As a first step to improvement, visualize your work flow.
I believe Alistair Cockburn phrased it this way: Kanban is reflective and adaptive, with reflection and adaption primarily triggered by examining the state of work.
What is Scrum?Scrum is a simple, team-based framework for solving complex problems. Scrum is based on successful patterns for developing products. Scrum implements a small set of patterns:
- Inspect and Adapt at regular intervals
- An interdisciplinary team solves the problem
- The team produces something the customer might value at regular intervals
- One voice speaks for the customers and stakeholders
- A coach helps the team and the organization get better
How are Scrum and Kanban similar?Both are reflective and adaptive. Kanban is focused on WIP whereas Scrum uses Time-boxing. If your product were a car, Scrum would be saying check your oil and tires every month, and Kanban would be the warning lights on the dashboard that turn red when something is amiss.
When I listened to David Anderson talking about his case studies, I thought a mature Kanban team is surprisingly similar to a mature Scrum team. What the Scrum Community call sprint planing and review takes on a strategic character, features get done during the sprint., not just at the end of the Sprint. Stories need to be trimmed to size. Scrum has sprints, Kanban has "cadence." You can even limit WIP in a sprint.
How has Kanban influenced my teaching of Scrum?I have recognized a couple of things:
- The easiest route to change starts with an agreement of the parties involved.
- If people look at how they work today, its well represented by Kanban
- If people think back to their best projects, they find a lot of commonality with Scrum. This recognition creates often creates a willingness to try Scrum.
- As it is primarily an attitude and a visualization tool, Kanban is applicable in some contexts where Scrum is not.
- As it is primarily an attitude and a visualization tool, Kanban does not directly address the people issues, especially at the team level.
I have found it most effective to consider Scrum to be a "reference implementation." No one will ever do it exactly like it is in the book, but they should do their best to get as close they can to the reference at the beginning. As they master it, their local improvements may very well take the team away from pure Scrum (think Spotify), but if they are inspecting and adapting frequently, it's OK.
By considering Scrum a point of departure, rather than a Nirvana to be achieved, we take away much of the pressure for compliance. This concept of Scrum as a standard to optimize from rather than a process to adhere to brings it philosophically in alignment with Kanban.
So I don't see an either-or. I use Kanban. I use Scrum. Let's get some work done!
Many organizations are reinventing themselves as we speak. One of the most difficult questions to answer is: which agile organizational model or framework do we use? SAFe? Holacracy? LeSS? Spotify?
Based on my experience on all these models, my answer is: just use as many agile models and frameworks you can get your hands on. Not by choosing one of them specifically, but by experimenting with elements of all these models the agile way: Inspect, Learn and Adapt continuously.
For example, you could use Spotify’s tribe-structure, Holacracy’s consent- and role principles and SAFe’s Release Trains in your new agile organization. But most important: experiment towards your own “custom made” agile organizational building blocks. And remember: taking on the Agile Mindset is 80% of the job, only 20% is implementing this agile "organization".
Probably the worst thing you can do is just copy-paste an existing model. You will inherit the same rigid situation you just wanted to prevent by implementing a scaled, agile organizational model.
Finally, the main ingredient of this agile recipe is trust. You have to trust your colleagues and this new born agile organization in being anti-fragile and self-correcting just right from the start. These principles are the same as successful agile organizations you probably admire, depend on.
We earned top honors at the 7th Annual NTC Awards on Thursday. Listen to CEO Chris Hefley talk about LeanKit's journey and share his advice for startups.
“The purpose of a business is to create a customer.” – Peter Drucker
So many people start with solutions, and then wonder where the customers are.
It’s the proverbial, “When all you have is a hammer, everything looks like a nail.”
The truth is, if all you have is a hammer, then get better at finding nails. And while you are looking for those nails, get better at expanding your toolbox.
If you want to be a better Entrepreneur or a trend hunter or a product manager or a visionary leader, then start with needs and wants. It will help you quickly cut through the overwhelm and overload of ideas, trends, and insights to get to the ideas that matter.
Some say the most valuable thing in the world is ideas. Many others say that coming up with ideas is not the problem. The problem is execution. The truth here is that so many ideas fail because they didn’t create a customer or raving fans. They didn’t address relevant pains, needs, and desired outcomes. Instead, they solve problems that nobody has or create things that nobody wants (unless it’s free), besides the creator, and that’s how you end up in the mad scientist syndrome. Or, ideas die because they were not presented in a way that speaks to the needs and wants, and so you end up a brilliant, misunderstood genius.Start Viewing the World Through the Lens of Human Needs and Wants
Here is some good insight and timeless truths on how to find trends that matter and how to create ideas that do, too from the 5 Trends for 2016 report by Trendwatching.com.
Via 5 Trends for 2016:
“Trends emerge as innovators address consumers’ basic needs and wants in novel ways.
As trend watchers, that’s why we look for clusters of innovations which are defining (and redefining) customer expectations.
Start by asking why customers might embrace you using a channel. Next, challenge whether existing channels really satisfy the deep needs and wants of your customers. Could you create any new ones? Finally, imagine entirely new contexts you could leverage (perhaps even those that customers aren’t yet consciously aware of).
As long as the onslaught of technological change continues, we’ll keep shouting this mantra from the rooftops: stop viewing the world through the lens of technology, and start viewing technology through the lens of basic human needs and wants.
Put another way: all those tech trends you’re obsessed with are fine, but can you use them to deliver something people actually want?”Start with Scenarios to Validate Customer Pains, Needs, and Desired Outcomes
A scenario is simply a story told from the customer's point of view that explains their situation and what they want to achieve.
They are a great tool for validating ideas, capturing ideas, and sharing ideas. What makes them so powerful is that they are a story told in the Voice-of-the-Customer (VOC). The Current State story captures the pains and needs. The Desired Future State captures the vision of the desired outcomes. Here is an example:
As a product manager, I'm struggling to keep up with changing customer behavior and band perception is eroding. Competition from new market entrants is creating additional challenges as we face new innovations, lower prices, and better overall customer experiences.
Desired Future State
By tapping into the vast amounts of information from social media, we gain deep customer insight. We find new opportunities to better understand customer preferences and perceptions of the brand. We combine social data with internal market data to gain deeper insights into brand awareness and profitable customer segments. Employees are better able to share ideas, connect with each other, connect with customers, and connect with partners to bring new ideas to market. We are able to pair up with the key influencers in social media to help reshape the story and perception of our brand.
Makes total sense right? But how often do you see anybody ever do this? That’s the real gap.
Instead, we see hammers not even looking for nails, but trying to sell hammers.
But maybe people want drills? No, they don’t want to by drills or drill-bits. They want to buy holes. And when you create that kind of clarity, you start to get resourceful and you can create ideas and solutions in a way that’s connected to what actually counts.You Might Also Like
Dit is een vraag die regelmatig door mijn hoofd speelt. In ieder geval moeten we stoppen met het continu romantiseren van deze initiatieven en als corporate Nederland nou eens echt mee gaan spelen.
Grofweg zijn er twee strategieën als corporate: opkopen of zelf beter doen! Klinkt simpel, maar is toch best wel complex. Waarschijnlijk is de beste strategie om een mix te kiezen van beide, waarbij je maximaal je eigen corporate kracht gebruikt (ja, die heb je), en tegelijkertijd volledig de kracht van start-up innovatie kunt gebruiken.
Deze post verkent de mogelijkheden en je moet vooral verder lezen, als ook jij wilt weten hoe jij de digitalisering van de 21ste eeuw wilt overleven.
Waarom moet ik hier iets mee?
Eigenlijk hoef ik deze alinea natuurlijk niet meer te schrijven toch? De gemiddelde leeftijd van bedrijven neemt af.
Dit komt mede doordat de digitalisering van producten en diensten de entree barrières in veel markten steeds lager maken. Er is dus meer concurrentie en daarom moet je beter je best doen om relevant te blijven.
Ten tweede, start-ups zijn hot! Iedereen wil voor een start-up werken en dus gaat het talent daar ook heen. Talent uit een toch al (te) krappe pool. Daarom moet je meer dan voorheen innoveren, omdat je anders de “war on talent” verliest.
Als laatste is er natuurlijk veel te winnen met digitale innovatie. De snelheid waarmee bedrijven tegenwoordig via digitale producten en diensten winstgevend kunnen worden is ongelofelijk, dus doe je het goed, dan doe je mee.
Wat zijn mijn mogelijkheden?
Er zijn eigenlijk maar twee manieren om met start-ups om te gaan. De eerste is om simpelweg een aandeel te nemen in een start-up of een veelbelovende start-up over te nemen. De andere is om zelf te gaan innoveren vanuit de eigen kracht in de organisatie.
De voordelen van aandelen en overnames is natuurlijk de snelle winst. De huid wordt vaak niet goedkoop verkocht, maar dan heb je ook wat. Helemaal mooi is het, de start-up actief is in een segment of markt, waar je zelf met je brand niet in wilt of kunt zitten (incumbent inertia). De nieuwe aanwinst is dan complementair aan de bestaande business. Bijvoorbeeld een grote bank, die een start-up overneemt die gericht is op het verkopen van kortlopend krediet aan midden- en kleinbedrijf.
Het nadeel is natuurlijk dat het moeilijk is om de bestaande assets over te hevelen. Bovendien wordt het nieuwe bijna nooit echt een onderdeel van de staande organisatie en misschien wil je dat ook helemaal niet. De kans bestaat namelijk dat de overgenomen start-up te veel beïnvloed wordt door het moeder bedrijf en daarom meegetrokken wordt door de zwaartekracht van bureaucratie en contraproductieve bestaande corporate gedragspatronen.
Daarbij komt, dat een succesvolle start-up vanzelf onderhevig wordt aan aanvallen van weer andere start-ups. De “kannibalen mindset” moet er in blijven! Facebook heeft daarom altijd gezegd, als wij ons eigen model niet disrupten, doet iemand anders dat wel. Misschien is het waar wat de CEO van Intel Andy Grove eens zei: “only the paranoid survive”.
Zelf innovatiever worden is natuurlijk ook een optie. Dat is echter behoorlijk complex. Meestal wordt innovatie binnen de corporate nog in een lab-setting geïsoleerd. Niet dat dit fout is, maar start-ups doen natuurlijk zoiets niet he. De start-up is namelijk het lab!
Het is grappig dat het lijkt alsof start-ups altijd nieuwe markten met nieuwe producten proberen te bereiken en dat we dit doorgaans bestempelen als “echte” innovatie. In een corporate setting worden namelijk alle product-marktcombinaties in een portfolio gezet (bijvoorbeeld een BCG-matrix) en gaat het om balans tussen huidige business en nieuwe business en de juiste cashflow verhoudingen.
Nou is het leuke dat start-ups maling hebben aan jouw portfolio en dus in elk kwadrant concurreren, zij het business die voor jou in de volwassenheid zit, of in de groei of in je lab-fase. Start-ups zijn simpelweg in de meerderheid en opereren los van elkaar op verschillende fronten. Dit betekent dat feitelijk iedereen in de corporate setting onder vuur ligt door start-ups en dus dat ook iedereen ongeacht de rol in het portfolio moet leren innoveren. Een voorbeeld van hoe waardevol het is om deze mindset te adopteren is het verhaal van deze jongeman uit 1973, hij werkte voor Kodak.
Je hele bedrijf veranderen is natuurlijk een ontzettende klus en als alternatief zou je ook kunnen kiezen om hetzelfde effect te creëren als bij een overname; het bewust lanceren van eigen start-ups voldoende los opgezet van de moederorganisatie om te versnellen. Deze eigen start-ups moeten directe concurrenten worden van de huidige business en zo succesvol worden dat iig een deel van de bestaande eigen en concurrerende business daar naartoe stroomt. Grote corporates kunnen zich op die manier meer en meer omvormen tot een netwerk van start-up nodes, waarbij het moeder bedrijf ondersteund en strategische complementaire nodes aankoopt waar nodig. Hoe zo’n node er uit ziet en hoe je dit organiseert is voer voor een volgende post.
Mocht je niet kunnen wachten en dit eerder willen weten dan kun je natuurlijk altijd bellen voor een gesprek.
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Is your agile transition proceeding well? Or, is it stuck in places—maybe the teams aren’t improving, maybe the people are multitasking, maybe you are tired and don’t know how you’ll find the energy to continue.
You are the kind of person who would benefit from the Influential Agile Leader event in Boston, April 6-7, and in London, May 4-5, 2016.
Gil Broza and I co-facilitate. It’s experiential, so you learn by doing. You practice your coaching and influence in the mornings. You’ll have a chance to map your organizational dynamics to see where to put your energy. You’ll split into smaller sessions in the afternoon, focusing on your business challenges.
If you would like to bring your agile transition to the next level, or, at the very least, unstick it, please join us.
Super early bird registration ends January 31 for London. Our super early bird for Boston is sold out, and the early bird registration is still a steal.
If you have questions, please post a comment or email me. Hope to work with you there.
Yesterday I bit the bullet and pushed out the 4.2.0 release. This was a fairly large internal refactoring, with the entire static API marked as obsolete and a new instance-based API exposed. Some helpful links for the move:
Some interesting things in this release that you might have missed:
- Dynamic/expando/dictionary mapping
- Expression translatation from expressions and queryables to/from source and destination types
It’s been a long journey with this static API, but its time is near the close. In the 5.0 release, the entire static API will be removed, making me quite happy.
Post Footer automatically generated by Add Post Footer Plugin for wordpress.
Scaled Agile Framework® (SAFe®) 4.0 clarifies many aspects of the framework that have been evolving since its inception. It also adds explicit support for the development of very large systems. Even so, you may still be finding your SAFe transformation a little more challenging than you expected.
Here’s how VersionOne can help with your SAFe 4.0 implementation:
3- and 4-Level SAFe
SAFe 4.0 introduces an optional fourth level to explicitly represent the Value Stream. The 4-level model is intended for large systems that realize customer value via the aggregation of features from multiple release trains into a solution.
VersionOne’s n-tier Project Tree enables you to easily create as many organizational tiers as needed. So whether you have a 3-level or 4-level SAFe implementation, or a combination of both models within the same enterprise, it’s just a matter of configuring the Project Tree.
Enterprise Kanban Systems
Multi-level Kanban is an important addition in SAFe 4.0. By having Kanbans at the Portfolio, Value Stream, and Program levels, Epics, Capabilities, and Features can all be visualized and managed for flow and economic benefit.
VersionOne has provided multi-level Kanbans for quite some time. Kanban Boards are configurable as appropriate at each level. By using Kanban boards, you configure your workflows, establish WIP limits to assure flow, provide real-time visibility for work in process, and drill into the underlying details as needed.
SAFe 4.0 also recognizes Kanban at the team level. By using TeamRoom™, VersionOne makes it easy for Kanban teams and iterative teams to coexist and collaborate within the same program.
Capabilities & Enablers
SAFe 4.0 has introduced two new portfolio item types: Capabilities and Enablers. Capabilities are aggregations of Features, and are the means by which solutions are delivered to customers at the Value Stream level. In VersionOne, a Capability is simply a Portfolio Item type. Configuring a Portfolio Item type is easy, and includes the ability to distinguish one type from another by color.
Enablers are technical undertakings that support Stories, Features, Capabilities, and Epics. Enablers may be found at all levels, so you might have Enabler Epics, Enabler Capabilities, Enabler Features, and Enabler Stories. Each of these can be configured as a Portfolio Item type or Story type. Some organizations prefer to keep their type lists as lean as possible, and opt to use a custom field to designate a Portfolio Item or Story an as Enabler. Either way will work.
Communities of Practice
SAFe 4.0 refers to Communities of Practice as “informational working groups designed specifically for efficient knowledge sharing and exploration across teams and groups of professions”. The idea is that as people become distributed across different teams and value streams, there needs to be a way to keep them connected. If “Communities of Practice” is too formal for your liking, Spotify’s “Chapters” and “Guilds” are different ways of expressing the same thing.
VersionOne Communities support your Communities of Practice by allowing people to communicate and collaborate on shared knowledge and “better practices” within the VersionOne platform.
Communities may also be used by your organization’s Agile Center of Excellence (or similar) to communicate guidance that applies across Teams, Programs, Value Streams, or Portfolios.
Although not new with SAFe 4.0, Strategic Themes are a key factor to succeeding with SAFe – especially with very large systems. That’s because they are the high-level enterprise business objectives that guide and constrain portfolio-level investment.
Once you’ve created your Strategic Themes in VersionOne, you can identify and group your Epics by Strategic Theme. Then, using VersionOne Budgets, you can make specific capacity, currency, or percentage allocations to your Strategic Themes, and then track progress against those allocations.
SAFe 4.0 advocates the allocation of budgets to Value Streams. VersionOne Budgets allow you to do just that. Budgeting can be allocated in terms of specific quantities of capacity or currency, or in terms of a percentage of the total. As work progresses, visualizations allow you to easily compare actuals to your planned budget.
As mentioned earlier, Budgets may also be allocated by Strategic Theme.
VersionOne also enables you to distinguish between work related to capital and operational expenses at any level that you need to track them. This facilitates CapEx and OpEx reporting.
VersionOne facilitates building quality in via its native Acceptance Test and Regression Testing capabilities, as well as its support for a wide selection of TDD, BDD, and ATDD tools.
SAFe 4.0 emphasizes agility and coordination throughout the enterprise. To enable the effective flow of value, software delivery and deployment processes must be tightly integrated across Teams, Programs, and Value Streams. In addition, as release batches become smaller, release velocity increases, and Value Streams become more complex, the ability to easily track and automate the flow of value all the way through production deployment becomes increasingly crucial.
More than simply DevOps automation, VersionOne Continuum™ is an enterprise-scale continuous delivery solution for orchestrating and visualizing the flow of change throughout the software delivery cycle. For an in-depth look at VersionOne Continuum, take a look here.
VersionOne is a Scaled Agile, Inc. Gold Certified Partner in both the Agile Tooling and Services categories. In addition to extensive support for SAFe 4.0, VersionOne’s Services team delivers training and consulting services through certified SAFe Program Consultants to help organizations implement and succeed with agile and the SAFe framework.
Interested in learning more? Join Dean Leffingwell for a free webinar to learn what’s new in each level of SAFe 4.0. Click here to register.
Continuum is a trademark of VersionOne Inc.
Scaled Agile Framework and SAFe are registered trademarks of Scaled Agile, Inc.
The team is proud to announce the release of 5.3, another paradigm-shifting version, with the addition of significant new features, and the return of popular functionality that didn’t make it in to 5.2:
- New Project Space which puts the focus on the Quality Gate and the Leak Period
- User tokens for authenticated analysis without passwords
- New web services to facilitate a build breaker strategy
- Cross-project duplication is back!
The most striking change in this version is the replacement of the default project dashboard with a new, fixed Project space highlighting the top four data domains: technical debt, coverage, duplications, and structure (which includes both size and complexity):
Because managing technical debt introduced during the Leak Period is so crucial, this streamlined, new project home page keeps the leak period (first differential period, which is now overridable at the project level), in the forefront. Both current and differential values are shown both textually and graphically:
Each of the four domains offers a detailed sub-page, available either through the “more” links on the Project Space or the relevant project menu items:Technical Debt:
Each domain page offers the same combination of current values (in blue, with clickthroughs) and leak period changes (yellow background) found on the main page, along with detailed numeric and graphical presentations designed to help you quickly zero-in on the worst offenders in your projects.
SonarSource feels so strongly about the value of the new Project Space and the domain pages that none of them are configurable. But your old dashboards are still available under the “Dashboards” menu item.User tokens for authenticated analysis without passwords
In version 5.2, we cut the last ties between analysis and the database. Now an analysis report is submitted to the server and all database updates take place server-side. In 5.3 we take the next step down the road of enhanced analysis security with the introduction of authentication tokens.
Now an administrator can create authentication tokens for any user.
Tokens may be used in for analysis and with web services. Simply pass the token as the login, and leave the password blank.
The list of user token names (but not values!) is easily visible, and existing tokens can be revoked at any time:
Users can’t generate their own tokens yet, but that’s coming soon.New web services to facilitate a build breaker strategy
In the implementation of a Continuous Inspection strategy, many people use Continuous Integration servers, such as Jenkins, to execute their SonarQube scans, and want to show as broken a run that includes new code that breaks fails the Quality Gate. Because of time constraints, the old hooks for that were removed in 5.2 and not replaced. In 5.3. we made it a priority to close this gap, so the functionality is now available to allow you to implement a build breaker strategy.
When the client-side scanner is done, it writes out a data file with the URL to call for the server-side processing status
Once the processing is successful,
you can use the analysis id to get the quality gate status
Also under the heading of returning favorites is cross-project duplication. The changes in 5.2 required serious API updates. In turn a rewrite of cross-project duplication detection was required – another priority in 5.3
Notably, 5.3 only provides cross-project duplication detection, not the detection of duplications across modules within a project, which is planned for 5.4.That’s All, Folks!
Watch this webinar to learn how to manage complex workflows in LeanKit.
Ponder this scenario…
Suppose you have an Agile team building applications based on data API’s that are managed by a services team. Suppose that you cannot change the structure of the organization. If changes are needed to get a different data field from the API in support of a feature in your app — what do you do?
The answer is a cross-team story. A cross-team story is really two parts: the validation piece of the story stays with the team that identified the need, and the actual development work story goes to the team that completes the work.
If both teams are running in Sprints, the shortest timeframe for completion of a cross-team story is two sprints. One sprint for the team doing the work, and one sprint for the validation of the team that identified the work.
A cross-team story workflow may look something like this:
1. During release planning or sprint planning, a team identifies work that must be delivered by a different team.
2. The team identifying the work creates two stories.
3. The product owners of the respective teams negotiate priority and scope of the story.
4. The team doing the work plans the story into their sprint. If the team doing the work uses a Kanban methodology, sprint planning is skipped and an expected date is communicated to the identifying team.
5. After the work is complete, the identifying team plays their validation story. This story could have been scheduled in a sprint based on the sprint, or an expected date from the work team.
6. When cross-team stories are identified prior to release planning there is an opportunity to play risk cards to ensure both teams are aware of the priority of the story, and the dependency can be manager by the Program Team or Portfolio Team. The tracking of the dependency can be accomplished in the Scrum of Scrums meetings.
In most organizations cross-team stories are rare. Many cross-team stories increase the risk of delay in delivery. If you notice that your team is always dependent on other teams to complete any functionality, this may be an indication that the skill set or architecture is not aligned with business priorities. This misalignment should be escalated to the Portfolio Team for resolution.
Several years ago, I was called to help an organization that was experiencing system outages in their call center. After months of outages and no effective action, they appointed an Operations Analyst to collect data and get to the bottom of the problem.
Once they had data, the managers met monthly to review it. At the beginning of the meeting, the Operations Analyst presented a pie chart showing the “outage minutes” (number of minutes a system was unavailable) from the previous month. It was clear from the chart which system the biggest source of outages for the month.
The manager for that system spent the next 40 minutes squirming as the top manager grilled him. At the end of the meeting, the top manager sternly demanded,“Fix it!”
By the time I arrived to help, they had many months of data, but it wasn’t clear whether any thing had improved. I dove in.
I looked at trends in the total number of outage minutes each month. I plotted the trends for each application, and created time series for each application to see if there were any temporal patterns. That’s as far as I could get with the existing data. In order to hone in on the biggest offenders, I needed to know not just the number of minutes a system was down, but how many employees and customers couldn’t work for when a particular system was down. One system had a lot of outage minutes, but only a handful of specialists who supported an uncommon legacy product used it. Another system didn’t fail often, but when it did, eight hundred employees were unable to access holdings for any customers.
Though they had data before I got there, they weren’t using it effectively. They weren’t looking at trends in total outage minutes… the pie chart showed the proportion of the whole, not whether the total number was increasing or decreasing over time. Because they didn’t understand the impact, they wasted time chasing insignificant problems.
When I presented the data in a different way, it led to a different set of questions, and more data gathering. That data eventually helped this group of managers focus their problem-solving (and stop pointing the roving finger of blame).
As a problem-solver, when you don’t have data, all you have to go on is your intuition and experience. If you’re lucky you may come up with a fix that works. But most good problem solvers don’t rely on luck. In some cases, you may have a good hunch what the problem is. Back up your hunches with data. In either case, I’m not talking about a big measurement program. You need good enough and “just enough” data to get started. Often there’s already some useful data, as there was for the call center I helped.
But what kind of data do you need? Not all problems involve factors that are easily counted, like outage minutes, number of stories completed in a sprint, or number of hand-offs to complete a feature.
If you are looking at perceptions and interactions you’ll probably use qualitative data. Qualitative data focuses on experiences and qualities that we can observe, but cannot easily measure. Nothing wrong with that. It’s what we have to go on when the team is discussing team work, relationships, and perceptions. Of course, there are ways to measure some qualitative factors. Subjective reports are often sufficient (and less costly). Often, you can gather this sort of data in quickly in a group meeting.
If you are using quantitative data, it’s often best to prepare data relevant to the focus prior to the problem-solving meeting. Otherwise, you’ll have to rely on people’s memory and opinion, or spend precious time looking up the information you need to understand the issue.
When I’m thinking about what data would be useful to understand a problem, I start with a general set of questions:
What are the visible symptoms?
What other effects can we observe?
Who cares about this issue?
What is the impact on that person/group?
What is the impact on our organization?
These questions may lead closer to the real problem, or at least confirm direction. Based on what i find, I may choose where to delve deeper, and get more specific as I explore the details of the situation
When does the problem occur?
How frequently does it occur?
Is the occurrence regular or irregular?
What factors might contribute to the problem situation?
What other events might influence the context?
Does it always happen, or is it an exception?
Under what circumstances does the problem occur?
What are the circumstances under which it doesn’t occur?
How you present data can make a big different, and may mean the difference between effective action and inaction, as was the case with the call center I helped
In a retrospective—which is a special sort of problem-solving meeting—data can make the difference between superficial, ungrounded quick fixes and developing deeper understanding that leads to more effective action—whether you data is qualitative or quantitative.
Here’s some examples how I’ve gathering data for retrospectives an other problem-solving meetings.Data TypeMethodExamples Notes QualitativeSpider or Radar ChartUse of XP practices.
Satisfaction with various factors.
Adherence to team working agreements.
Level of various factors (e.g. training, independence)
Shows both clusters and spreads.
Highlights areas of agreement and disagreement.
Points towards areas for improvement. Leaf ChartsSatisfaction. Motivation.
Severity of issues.
Anything for which there is a rating scale.Use a pre-defined rating scale to show frequency distribution in the group.
Similar to bar charts, but typically used for qualitative data. Sail boat (Jean Tabaka)Favorable factors (wind), risks (rocks), unfavorable factors (anchors), Metaphors such as this can prompt people to get past habitual thinking. TimelinesProject, release, iteration. events over time. Events may be categorized using various schemes. For example:
technical and non-technical
levels within the organization (team, product, division, industry).Shows patterns of events that repeat over time. Reveals pivotal events (with positive or negative effects). Useful for prompting memories, showing that people experience the same event differently. TablesTeam skills profile (who has which skills, where there are gaps)Shows relationships between two sets of information. Shows patterns. TrendsSatisfaction. Motivation.
Severity of issues.
Anything for which there is a rating scale.Changes over time. QuantitativePie ChartsDefects by type, module, source.
Severity of issues. Shows frequency distribution. Bar ChartsBugs found in testing by module + bugs found by customers by module.Frequency distribution, especially when there is more than one group of things to compare. Similar to histograms, but typically used for quantitative data. HistogramsDistribution of length of outages.Frequency of continuous data (not categories). TrendsDefects.
Shows movement over time. Often trends are more significant than absolute numbers in spotting problems. Trends may point you to areas for further investigation—which may become a retrospective action. Scatter PlotsSize of project and amount over budget.Show the relationship between two varianles. Time SeriesOutage minutes over a period of time.
Through-put.Show patterns and trends over time. Use when the temporal order of the data might be important, e.g., to see the effects of events. Frequency TablesDefects
Stories accepted on first, 2nd, 3rd, demo.A frequency table may be a preliminary step for other charts, or stand on its own. Data TablesImpact of not ready stories.Show the same data for a numberr of instances.
I am shepherding an experience report for XP 2016. A shepherd is sort-of like a technical editor. I help the writer(s) tell their story in the best possible way. I enjoy it and I learn from working with the authors to tell their stories.
The writers for this experience report want to pair-write. They have four co-authors. I offered them suggestions you might find useful:Tip 1: Use question-driven writing
When you think about the questions you want to answer, you have several approaches to whatever you write. An experience report has this structure: what the initial state was and the pain there; what you did (the story of your work, the experience); and the end state, where you are now. You can play with that a little, but the whole point of an experience report is to document your experience. It is a story.
If you are not writing an experience report, organize your writing into the beginning, middle, end. If it’s a tips piece, each tip has a beginning, middle, end. It depends on how long the piece is.
When you use question-driven writing, you ask yourself, “What do people need to know in this section?” If you have a section about the software interacting with the hardware, you can ask the “What do people need to know” and “How can I show the interactions with bogging down in too much detail” questions. You might have other questions. I find those two questions useful.Tip 2: Pair-write
I do this in several ways with my coauthors. We often discuss for a few minutes what we want to say in the article. If you have a longer article, maybe you discuss what you want to discuss in this section.
One person takes the keyboard (the driver). The other person watches the words form on the page (the navigator). When I pair-write with google docs, I offer to fix the spelling of the other person.
I don’t know about you, but my spelling does not work when I know someone is watching my words. It just doesn’t. When I pair, I don’t want the writer to back up. I don’t want to back the cursor up and I don’t want the other person to back up. I want to go. Zoom, zoom, zoom. That means I offer to fix the spelling, so the other person does not have to.
This doesn’t work all the time. I’m okay with the other person declining my offer, as long as they don’t go backwards. I become an evil witch when I have to watch someone use the delete/backspace key. Witch!Tip 3: Consider mobbing/swarming on the work
If you write with up to four people (I have not written with more than four people), you might consider mobbing. One person has the keyboard, the other three make suggestions. I have done this just a few times and the mobbing made me crazy. We did not have good acceptance criteria, so each person had their own idea of what to do. Not a recipe for success. (That’s why I like question-driven writing.)
On the other hand, I have found that when we make a list of sections—maybe not a total outline—pairs of people can work on their writing at the same time. Each pair takes a section, works on that, and returns to the team with the section ready for review. I have also been in a position where someone did some research and returned to the writing team.
I have also been in a position where someone did some research and returned to the writing team.Tip 4: Use a Short Timebox for Writing
When I pair, I write or navigate in no more than 15-minute timeboxes. You might like an even shorter timebox. With most of my coauthors, I don’t turn on a timer. I write for one-to-several paragraphs and then we switch. We have a little discussion and then we’re writing again. Most of my timeboxes are 5-7 minutes and then we switch.Pair Writing Traps
I have seen these traps when pair-writing:
- One person dictates to the other person. That smacks of first-author, all-the-rest-of-you-are-peons approach.
- One or both of you talk without writing. No. If someone isn’t writing in the first 90 seconds, you’re talking, not writing. Write. (This is the same problem as discussing the design without writing code to check your assumptions about the design.)
I didn’t realize I would make this a series. The post about writing by yourself is Four Tips to Writing Better and Faster.
I have a special registration for my writing workshop for pairs. If you are part of a pair, take a look and see if this would work for you.