[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
One of the -ilities people try to build into their software is maintainability. It’s been that way for as long as I can remember (although as I grow older, my memory grows shorter).
As the pace of change continues to increase, the necessity for IT organizations to be able to deliver on demand also increases. We’re on the look-out for anything that can enable this: continuous integration, heavy test automation, Behavior-Driven Development, DevOps, automated deployment, resilient infrastructures that can adjust dynamically to changing workloads or server outages, reactive architectures that flex under user demand.
A maintainable application may not be up to these challenges. The idea of “maintainability” implies that the application is a long-term artifact; a cathedral or a Great Pyramid. But keeping up with the demand for change may call for something a little different: Applications that can be discarded and replaced rapidly with no negative impact to customers, low risk, and low cost.
The situation calls for a new -ility: Replaceability.
Your first reaction may be, “We can’t do that.” You’re right. You can’t do that today. The appropriate question to ask when we want to do something that we can’t do today is this:
What would have to be true that is not true now in order to enable the New Thing?Strategic and Tactical Assets
The first prerequisite that I can see is we must explicitly decide which applications are tactical and which are strategic. I think the idea of replaceability pertains to tactical assets, and not strategic ones.
If you have a well-designed SOA environment, you can start by assuming most of the applications in the “core” are strategic and most of the applications that interact with core assets through the service layer are tactical.
Most organizations don’t have a well-designed SOA environment. How can we begin if we don’t have that advantage? I think we can consider what types of IT assets are central to our business operation.
Here’s a suggested taxonomy, for discussion purposes.
- Data-centric operations
- Transaction-centric operations
An organization for which data is central to operations is data-centric. I will suggest these types of businesses, for starters:
- an advisory company for investors
- a company that collects information about vehicle histories
An organization for which high-volume, fast transaction processing is central to operations is transaction-centric. I will suggest these types of businesses:
- a social media service
- a mass marketing company
An obvious objection arises to this taxonomy: All these types of businesses are centered on data in one way or another. Clearly, the investment advisory company collects and analyzes data about stocks, and the vehicle history company collects data about events in the lives of vehicles. But the social media company and mass marketing companies are in the data business, as well. The former sells information about users and their preferences, and the mass marketing company depends on scrubbed mailing lists or phone lists to maximize the response rate of mass marketing campaigns. Aren’t they all data-centric businesses?
The key as I see it is to look at the question from the perspective of IT operations. In the first two cases, the collection of data is critically important. It has to be clean, consistent, accurate, and readily accessible. Tactical applications are like windows into the data, and clients of the algorithms that make sense of the data. The data and the algorithms are the strategic assets in that case.
In the cases of the social media service and the mass marketing firm, there can be a great deal of noise in the data without affecting the business negatively. It’s more critical that they can process a very large number of transactions quickly. They don’t even require an ACID database. Dirty reads are okay. Updates that catch up “eventually” are okay. But the transaction processing has to be absolutely rock-solid.
Another difference pertains to the “stickiness” of the data. The investment advisor and the vehicle history reporter need to keep long-term historical data intact. The longer the history, the better the information they can report to their customers.
The social media service and the mass marketer don’t need to keep information about customer preferences or customer addresses and phone numbers for the long term. Those categories of information tend to be transient. People’s tastes change over time as they go through different stages of life. People relocate and change phone numbers from time to time. And it’s easy enough to start over; certainly not the same impact as for the performance history of an investment instrument.Considerations for Strategic Assets
Once we’ve determined which IT assets are strategic and which are tactical, we can apply appropriate considerations to the selection and support of each type.
In my view, the following considerations apply to strategic assets:
- Vendor relationship: Partner
- Key product selection criteria: Unique features of a particular product
- Budget for support: High
- Cost of replacement: High
The new -ility, replaceability, doesn’t apply to strategic assets. We will intentionally lock ourselves into a specific product because of the special features it offers that help support our business needs. We won’t relate to the vendor as a customer, but rather we will establish a partnership arrangement with them. We need close and immediate support for anything and everything pertaining to our strategic assets. To get that, we’ll budget more to support these assets than we will to support tactical ones. We’ll also accept the fact that should the need arise to replace a strategic asset, doing so will involve significant effort and cost. We don’t plan to change strategic assets frequently.
An aside: What’s the implication for Agile development? Changes in strategic assets will tend to be characterized by low uncertainty, low time-to-market pressure, and a need for significant up-front analysis and planning. This is not the sweet spot for conventional Agile methods.
What does it mean to replace a tactical asset? For the investment advisory firm, the data and the analysis algorithms are strategic assets. Web-based or mobile clients are merely “windows” into those assets. These client applications should be replaceable quickly at low cost and with low risk. Replacing, say, a .NET webapp with a Ruby webapp should have zero impact on the central data store or on the code that performs investment analysis.Considerations for Tactical Assets
In my view, the following considerations apply to tactical assets:
- Vendor relationship: Customer/supplier
- Key product selection criteria: Adherence to vendor-neutral standards
- Budget for support: Low to moderate
- Cost of replacement: Low
This is the area in which replaceability becomes a critical success factor for the enterprise.
Although most organizations lack a well-defined SOA infrastructure, each tactical application will have some way of interacting with strategic assets. In an established organization there will almost always be a range of different methods: point-to-point interfaces, file-sharing, SOAP services, RESTful services, RPC, cross-memory services…you name it. This model doesn’t depend on any particular technical implementation. Old technologies fit into the model the same way as newer ones.
The key point is we don’t want any baked-in dependencies on product-specific features above and beyond “plain vanilla” support for vendor-neutral standards. We expect to replace these applications from time to time, and when we do so we don’t want to hit a wall of technical issues. A web server is a web server; a rules engine is a rules engine; a SQL database is a SQL database. We don’t want to configure tactical assets in a way that will add cost or delay to their replacement.
An aside: What’s the implication for Agile development? Changes to (or replacement of) tactical assets will tend to be characterized by high time-to-market pressure and high means uncertainty, even if not by high-end uncertainty. This is the sweet spot for adaptive approaches such as Agile development.
What does it mean to replace a tactical asset? Let’s say the social media service grows from 100 million users to 1 billion users, and the document database they were using is no longer providing the transaction times they require. They want to switch to a graph database or a relational database. They need to be able to do this with a minimum of hassle. They will have to reformat the data; hopefully, that can be done with a script. But there are always “gotchas.” Our goal is to keep everything as simple as we can on the tactical level, to minimize the number and difficulty of the inevitable “gotchas.”Enabler 1: Specification by Example / Behavior-Driven Development
You might argue that we’ve tried to replace applications in the past, and it was always a hassle. How many “it’s just a rewrite” projects have we lived through? I’ve lost count. I guess you have, too.
We need a practical way to be sure we haven’t overlooked some important feature when we replace a tactical application. As far as I know, there’s no magical way to do this. However, there is a technology that offers a pretty good partial solution: The text-based “language” known as Gherkin.
Gherkin is a specification for formatted text that is designed to support Specification by Example or Behavior-Driven Development. The interesting thing about Gherkin for purposes of replacing a tactical application is that it is technology-agnostic. The only thing you would ever have to change when moving Gherkin specifications from one platform to another is the line endings, if you were moving to or from Microsoft Windows. Any Gherkin interpreter on any platform can process standard Gherkin text files.
Gherkin won’t help if we’re replacing one database management system with another, but in that sort of replacement we don’t have the concern about overlooking a functional requirement. Gherkin can help with replacing a “window” application that accesses strategic assets. The user-observable behavior of the application can be captured in the form of Gherkin scenarios, which can then be used to ensure the new application supports the same functionality as the old one.
There’s no real cost involved in using Specification by Example or Behavior-Driven Development. These techniques are merely a question of self-discipline on the part of technical professionals. Gherkin interpreters for just about any platform and any programming language are free downloads. The value of these practices extends not only to clarity about requirements, automated functional checking, and dependable documentation, but also helps support the idea of replaceability for tactical applications.
Therefore, one way to help prepare the ground for separating strategic and tactical assets is to back-fill functional specifications for existing applications in Gherkin. This can be done incrementally over time.Enabler 2: Separation of Concerns
In working with legacy applications, we need to pay attention to separation of concerns. In particular, the code that communicates across the “boundary” between the strategic and tactical worlds has to be loosely coupled with the rest of the application code. This applies both to strategic applications and tactical ones.
Consider the case when a social media service wants to replace the database management system. The strategic transaction-processing code should not be affected by this change. The only parts of that code that should be affected are the layers or components that directly interact with the database. Strategic functionality must be unaware of any changes to the database implementation.
Therefore, one way to help prepare the ground for separating strategic and tactical assets is to refactor legacy applications to ensure clean separation of concerns. This can be done incrementally over time.Summary
To meet emerging demands for rapid change, IT organizations need to consider ways to enable very fast replacement of technical assets that are liable to be affected by changes in the market or in business direction. By separating strategic and tactical IT assets, we can take steps to ensure it will be easy, fast, and cheap to replace tactical assets, while still enjoying the benefits of tight integration with the special features of strategic products that support our business operations. Thinking about IT assets in this way helps us understand where to focus our budget and effort to achieve maximum value with minimal overhead.
Is Agility limited to software? Ron Jeffries (l) and Steve Denning at Agile 2016
Photo thx to Steve Denning Steve Denning has collected the evidence and laid out the case that Agile is not limited to software, nor is it merely a process, nor is it something you can do with part of your time, nor is it something you can have your staff do. Agile is a mindset, and this mindset is applicable to many if not all fields of endeavor.1 At the same, he questions whether the mindset is actually defined in the Agile Manifesto.2
What is this mindset? Where does it come from? How do you know that you or your company has it? And is it really missing from the Agile Manifesto?
There is no question that Steve is correct in his assertion that Agile is a mindset. Practitioners have known this since the beginning. I remember my first interview, back in 2008 or so, for employment at an Agile consulting company. The mindset question was my interview partner's key question, and I couldn't explain it. (No, I didn't get the job.) In 2009, I opened the first Lean Agile Scrum Conference in Zurich with the thought, “In 2001, we started uncovering better ways of developing software. Since then, we have uncovered the need for better ways to lead organizations.”
More recently, the importance of the Agile mindset was the key finding of the Scrum Alliance Learning Consortium:
“A universal feature of all the site visits was a recognition that achieving these benefits [of Agile values and practices] is dependent on the requisite leadership mindset. Where the management practices and methodologies were implemented without the requisite mindset, no benefits were observed.... What is new is the way that the new management goals, practices, and values constitute a coherent and integrated system, driven by and lubricated with a common leadership mindset.”
Denning, Goldstein and Pacanowsky. 2015 Report of the Learning Consortium I believe The Manifesto for Agile Software Development (“the Agile Manifesto”) does define a mindset. This mindset leads you to the 4 values, 12 principles, and uncounted practices that are helpful in software development. This mindset also leads you to the five shifts of Radical Management, which are much more generally applicable.
Agility starts in the headIf Agility is mindset, then it starts in the head. It starts in the head of each individual. It starts in the head of the company, i.e. its leadership team, and it starts in the heads of the individuals that make up the leadership team.
I believe that you can assess the Agility of an organization through five simple questions, all derived from the Agile Manifesto, even if they are not primarily developing software. You can ask these questions to their leadership, and you can get confirmation from by asking their staff or customers the same questions.
Let's look at how the Agile Manifesto defines the mindset, then derive a set of questions based on that mindset. Let's take the case of a hypothetical railway: How would a railway apply the Agile Manifesto? How could an organization that values operational goals, like having the trains run on time, be Agile as well?
The most neglected part of the Agile Manifesto?Quickly! What is the first sentence of the Agile Manifesto? If you said something about “people and interactions over tools and processes,” you got the wrong answer! But don't feel bad. At the last Scrum Gathering in Bangalore, I asked 5 Scrum trainers the same question, and only one of them got the right answer! Here are the first sentences of the Agile Manifesto:
“We are uncovering better ways of developing software, by doing it and helping others to do it. Through this work we have come to value…”How come no one talks about the first sentence? It carries so many messages! For example:
- We are doing. It's not about software quality, it's about uncovering better ways to develop software. It's about the process and not the result.
- We don’t have the best practices, we are constantly looking for better practices. We are open to the possibility that someone else has a better idea.
- We expect to be better tomorrow than we are today, so we maintain a certain humility about our knowledge today.
- We are helping others to do the same. Not teaching, helping! Sharing knowledge, especially beyond the borders of our own organization, enables our own learning, enables us to learn from others, and builds overall knowledge faster. This clause defines our relationship to other people and organizations.
We are uncovering better ways of doing what we do, by doing it and helping others to do the same. The first question is, what exactly does our train system do? Run trains? Transport people and goods throughout the country? Something else? They might try this one on for size:
We are uncovering better ways of running the trains on time, by doing it and helping others to do the same...What if our rail system incorporated this statement in its mission? How would that railway be different than the ones we know today? Simon Synek, in his famous work Start with why, gives us a clue:
“One by one, the German luxury car makers begrudgingly added cup holders to their fine automobiles. It was a feature that mattered a great deal to commuter-minded Americans, but was rarely mentioned in any research about what factors influenced purchase decisions.”For context, Chrysler introduced modern cup holders with the Chrysler Voyager back in 1983o3. My 1993 BMW 3-Series did not have them. My 2001 BMW 5 Series had pretty flimsy cupholders, and my wife's 2011 BMW 5 Series finally has pretty good cup holders.
What was missing here? A culture of learning, particularly of learning from outside the organization. An Agile organization is a learning organization. An Agile organization will be looking for, validating and embracing new ideas quickly, so that they can get better at doing what they do.
What does it mean to have an “Agile Mindset?” At the very least, someone who has the mindset is in alignment with the first sentence of the Agile Manifesto: We are uncovering better ways of doing what we do, by doing it, and helping others to do the same.
The first question: What do you do? What does your organization do for its customers or stakeholders? The answer must contain a verb, and should represent something of value to your customers or stakeholders. So making money is not what you do. It is a result of what you do.
Even the choice of mission says something about what the organization values, which may in turn determine its ability to meet the challenges of the 21st century. If our train system just wants to run the trains on time, how capable will it be to respond to new market challenges like digitalization (Uber, Zipcar, Mobility) or technological advancement (electric cars, self-driving cars)?
The second and third questions:
Uncovering better ways of doing thingsAre you uncovering better ways of doing what you do, by doing it? This is about your culture of change and improvement. If you prefer the status quo, you are unlikely to be uncovering better ways of doing what you do.
Are you uncovering better ways of doing what you do, by helping others to do the same? “Helping” is a peer-to-peer activity, not a top down activity. So this not about getting training for your staff, this is about advancing the state of your art, having time to improve skills and technology, and learning and sharing beyond your own four walls.
What do you value?The Agile Manifesto defines 4 value pairs:
“Through this work we have come to value:
Individuals and interactions over processes and tools
[Customer visible value] over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.”As above, I have replaced “Working Software” with “Customer visible value” to make it a bit more general. The first of the twelve principles are:
- Our highest priority is to satisfy the customer through early and continuous delivery of [Customer visible value].
- Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
By putting valuable things in relationship to one another, Agile values become a tool to guide decision making, which in turn enables more distributed decision making.
Must an organization embrace these values to be an Agile organization? This is a harder question, because context can be very different. What would an Agile police force or military unit choose to value? What would our hypothetical train system value?
As a frequent user of the Zurich public transportation system, I believe that they want to provide a high level of service to their customers, defined as on-time performance, frequent connections, ease of use, and comfort. But if they catch you without ticket, they have no mercy, and they don't care about your reasons!
Ensuring compliance with ticketing rules or showing compassion to loyal customers? How would our Agile train system decide this case? Would they want to handle it differently? Answering this question requires thought, and who is best positioned to make this decisions? The people who understand the problem best.
What other conflicting values might our train system choose to evaluate? For example:
- An easy-to-remember time table or having enough seats for all passengers?
- Trains departing on time or passengers making their connections when their train is late?
- Minimizing operating costs or having a train available frequently and regularly?
- Ensuring compliance with ticketing rules or showing compassion to loyal customers?
Questions 4 and 5: What do you value?Have you reflected on the values and principles of the Agile Manifesto and what they mean for you? Can you concisely explain your values and why you value them?
What do your staff and customers think?It may be possible to kid yourselves, but kidding your customers and staff is much harder. So ask yourself:
- On a scale of 0 to 10 (highly unlikely to highly likely), how likely are your customers or staff to describe your company as an Agile organization?
Peter's 5 Question AssessmentIf you can concisely answer the first question and answer yes to the remaining questions, then I believe you can say you have an Agile mindset. If your company and its leadership can answer yes to these same questions, then I believe you can claim that your company is an Agile organization:
- What do you do (besides make money)?
- Are you uncovering better ways of doing what you do, by doing it?
- Are you uncovering better ways of doing what you do, by helping others to do the same?
- Have you reflected on the values and principles of the Agile Manifesto and what they mean for you?
- Can you concisely explain your values and why you value them?
- On a scale of 0 to 10 (highly unlikely to highly likely), how likely are your customers, stakeholders, or staff to describe you as being Agile?
I have created a one page questionnaire which you can use to conduct this assessment. You can download it both in source from (LibreOffice) and as a PDF. I call it release candidate one, because it is a work in progress. Feel free to try it out, and please send me suggestions, improvements, and data!
1 What is Agile?
2 What's missing in the Agile Manifesto?
3 The History of the Car Cup Holder
Agile methoden zoals Scrum leggen de nadruk op functionaliteit. Klanten verwachten echter naast functionaliteit dat ook de kwaliteit van het product in orde is. Waar Agile voornamelijk aandacht geeft aan het software team en de interactie met de omgeving, kijkt Lean naar de gehele keten: van klantbehoefte tot waarde voor de klant. Een van de aspecten van Lean Software Ontwikkeling is het integreren van kwaliteit.
Lean Software Ontwikkeling combineert Agile en Lean met de volgende 7 principes:
- Verminder Verspillingen (Eliminate Waste)
- Integreer Kwaliteit (Build Quality In)
- Leer Voortdurend (Learn Constantly)
- Lever Snel (Deliver Fast)
- Betrek Iedereen (Engage Everyone)
- Verbeter Continue (Keep getting Better)
- Optimaliseer het Geheel (Optimize the whole)
Retrospectives Exercises Toolbox - Design your own valuable Retrospectives
Mijn definitie van kwaliteit (zie Hoe zorg je met Scrum voor Kwaliteitsproducten en Diensten) is:
Kwaliteit is de mate waarin voldaan wordt aan de behoeften van de gebruikers, en aan de eisen van de opdrachtgevers. Dat kunnen zowel functionele behoeften zijn (iets wat het product of dienst moet doen), of “performance”of niet-functionele eisen (hoe snel, hoe veel, de betrouwbaarheid, etc), vaak is het een combinatie van beide.
Het zijn je klanten die bepalen wat kwaliteit is (en wat niet), en wat vereist is voor een goede kwaliteit. Pas als je weet wat je klanten nodig hebben kun je naar goed oplossingen zoeken om aan hun wensen te voldoen. Je integreert daarmee kwaliteit in het gehele ontwikkelproces. Het juiste product
Hoe kom je erachter wat de klant nodig heeft? Agile kent diverse practices waarin het team en de klanten (in de Scrum praat men over product owner ipv klant) intensief samenwerken om ervoor te zorgen dat het juiste product geleverd wordt. Voorbeelden daarvan zijn de planning game en de product demonstratie.
In de planning game gaat het erom dat de product eisen duidelijker worden. Wat willen klanten bereiken met het product, welke waarde moet het hun gaan bieden? Wat moet het product doen om die waarde te kunnen leveren? Maar ook de kwaliteitseisen: hoe snel moet het werken, en hoe betrouwbaar en stabiel moet het zijn? Het team benut zijn kennis en ervaring om te bepalen wat mogelijk is, en hoe het product op een Lean manier ontwikkelt kan worden.
In de product demonstratie laat je het product zien aan de klanten en vraag om je feedback. Is dit wat de klant wil? Is het goed genoeg? Maar ook: Is het snel genoeg, handig te gebruiken. Betrouwbaar en veilig? En, gegeven wat het product nu doet, wat is er nog meer nodig? Kwaliteit met Agile en Lean
Hoe gaat dat in de praktijk? Laten we kijken naar een medisch systeem wat specialisten gebruiken om onderzoek te doen met patiënten. De specialisten (klanten) willen een aantal mogelijkheden hebben om data en scans van een patiënt te bekijken. Ze willen beelden van eerdere scans kunnen oproepen, inzoomen, en vergelijken. Omdat ze dat vaak met de patiënt erbij doen moet dat snel gaan, en eenvoudig te bedienen zijn. De gegevens mogen niet fout zijn, de specialisten gebruiken ze om beslissingen te nemen waar het leven van de patiënt van af kan hangen.
In de discussies vooraf en in de planning game formuleren de product owner en het team de acceptatie criteria. Voor kwaliteitseisen moeten die criteria meetbaar zijn. Dus niet “snel genoeg” maar “in 90% van de gevallen reageert het systeem binnen 1 seconde”.
Samen met de product owner formuleren de teamleden user stories. De acceptatiecriteria in de user stories worden door het team gebruikt om af te spreken hoe ze de software gaan maken en verifiëren.
Bijvoorbeeld, voor een bepaalde user story doen ze een spike, ze maken een stukje sofware en een testcase die meet hoe snel de software is om te bepalen of wat de klant wil haalbaar is. Voor een andere user story wil het team pair programming gebruiken, het is een complexe functie waarmee de team leden nog geen ervaring hebben.
Er zijn ook stories waarbij test driven design volgens het team de beste aanpak is, en een enkele story waarbij de klant nog niet echt weet wat het product precies moet gaan doen om er op een handige manier mee te kunnen werken, daar lijkt prototyping met Lean Startup het beste te passen.
De vereiste functionaliteit en kwaliteit is bepalend voor de aanpak. De product owner maakt duidelijk wat er nodig is en welke kwaliteit de klanten verwachten. Het team weet wat met een bepaalde manier van werken haalbaar is, en check in de planning game met de product owner. Te weinig kwaliteit is niet goed, maar teveel ook niet. Het gaat bij lean om het vinden van de juiste balans tussen tijd, geld en kwaliteit voor het leveren van functionaliteit.
In de demonstratie wordt de software getoond en gechecked of het voldoet. Daarbij telt zowel de functionaliteit als de kwaliteit. Het moet niet alleen werken, het moet ook snel genoeg zijn, betrouwbaar, bedienbaar, etc. Pas dan voldoet het product aan alle eisen en is het af.
De kracht zit in de samenwerking tussen het team en de product owner gedurende de ontwikkeling. Is er een gedeeld beeld wanneer, hoe en waarvoor klanten het product gebruiken? Wat betekent het product voor hun en welke waarde het kan toevoegen? Kan de product owner voldoende duidelijk maken wat nodig is, en checken de teamleden of ze het goed begrepen hebben? Leren ze van dingen die niet goed zijn gegaan? Integreer kwaliteit
Lean en Agile versterken elkaar als het gaat om de kwaliteit van de producten en diensten. Met agile en lean practices integreer je kwaliteit in de volledige productontwikkelingsketen.
In de workshop software kwaliteitsverbetering leer je hoe je goede producten en diensten kunt leveren. Kwaliteitsverbetering helpt organisaties om beter te voldoen aan de behoeften van de gebruikers en aan de eisen van de opdrachtgevers.
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Our latest Android release is going to make communicating with colleagues a lot easier. You are now able to mention people in comments and share photos from your device.Mentions
Previously, you were able to view an entity’s attachments and photos but could not add new ones. Now, you can.
Open the Attachments tab and choose a way to add pictures: select an existing one from your device, or take a new one with your camera.
We’re working on improving navigation and general ease of use for our next Android release. Until then, feel free to let us know if you have any feedback or comments to share with our team – just shoot us an email at firstname.lastname@example.org.
Mijn artikel Continue Verbetering met Agile is gepubliceerd in Bits&Chips nr 4. In dit artikel laat ik zien dat continue verbetering een integraal onderdeel is van de Agile-mindset en van de Agile-principes en -practices, en geef ik tips en advies voor verbeteren met agile:
Silver bullets bestaan niet in softwareontwikkeling. Effectieve softwareteams bepalen zelf hoe ze hun werk doen, passen zich continu aan en verbeteren zichzelf. Continue verbetering is ingebed in de Agile-mindset en -principes en helpt zo om de flexibiliteit in bedrijven te verhogen en meer waarde te leveren, betoogt Ben Linders.
Retrospectives Exercises Toolbox - Design your own valuable Retrospectives
Eerder dit jaar publiceerde Bits&Chips een Engelstalige editie, met daarin mijn artikel Delivering quality software with Agile.
Welcome to our first #GitKrakenTip video where you’ll learn about some helpful GitKraken features that you may, or may not, already know about. Either way, you’ll be entertained (with a little luck) and get to know some of our team members who actually make GitKraken.
In this short video, Tania Katan, Axosoft Evangelist, has lost her keys and is about to lose her mind. Enter, Jordan Wallet, a GitKraken Dev, who saves the day.
Story points are a unit of measure for expressing an estimate of the overall effort that will be required to fully implement a product backlog item or any other piece of work.
When we estimate with story points, we assign a point value to each item. The raw values we assign are unimportant. What matters are the relative values. A story that is assigned a 2 should be twice as much as a story that is assigned a 1. It should also be two-thirds of a story that is estimated as 3 story points.
Instead of assigning 1, 2 and 3, that team could instead have assigned 100, 200 and 300. Or 1 million, 2 million and 3 million. It is the ratios that matter, not the actual numbers.What Goes Into a Story Point?
Because story points represent the effort to develop a story, a team’s estimate must include everything that can affect the effort. That could include:
- The amount of work to do
- The complexity of the work
- Any risk or uncertainty in doing the work
When estimating with story points, be sure to consider each of these factors. Let’s see how each impacts the effort estimate given by story points.The Amount of Work to Do
Certainly, if there is more to do of something, the estimate of effort should be larger. Consider the case of developing two web pages. The first page has only one field and a label asking to enter a name. The second page has 100 fields to also simply be filled with a bit of text.
The second page is no more complex. There are no interactions among the fields and each is nothing more than a bit of text. There’s no additional risk on the second page. The only difference between these two pages is that there is more to do on the second page.
The second page should be given more story points. It probably doesn’t get 100 times more points even though there are 100 times as many fields. There are, after all, economies of scale and maybe making the second page is only 2 or 3 or 10 times as much effort as the first page.Risk and Uncertainty
The amount of risk and uncertainty in a product backlog item should affect the story point estimate given to the item.
If a team is asked to estimate a product backlog item and the stakeholder asking for it is unclear about what will be needed, that uncertainty should be reflected in the estimate.
If implementing a feature involves changing a particular piece of old, brittle code that has no automated tests in place, that risk should be reflected in the estimate.Complexity
Complexity should also be considered when providing a story point estimate. Think back to the earlier example of developing a web page with 100 trivial text fields with no interactions between them.
Now think about another web page also with 100 fields. But some are date fields with calendar widgets that pop up. Some are formatted text fields like phone numbers or Social Security numbers. Other fields do checksum validations as with credit card numbers.
This screen also requires interactions between fields. If the user enters a Visa card, a three-digit CVV field is shown. But if the user enters an American Express card, a four-digit CVV field is shown.
Even though there are still 100 fields on this screen, these fields are harder to implement. They’re more complex. They’ll take more time. There’s more chance the developer makes a mistake and has to back up and correct it.
This additional complexity should be reflected in the estimate provided.Consider All Factors: Amount of Work, Risk and Uncertainty, and Complexity
It may seem impossible to combine three factors into one number and provide that as an estimate. It’s possible, though, because effort is the unifying factor. Estimators consider how much effort will be required to do the amount of work described by a product backlog item.
Estimators then consider how much effort to include for dealing with the risk and uncertainty inherent in the product backlog item. Usually this is done by considering the risk of a problem occurring and the impact if the risk does occur. So, for example, more will be included in the estimate for a time-consuming risk that is likely to occur than for a minor and unlikely risk.
Estimators also consider the complexity of the work to be done. Work that is complex will require more thinking, may require more trial-and-error experimentation, perhaps more back-and-forth with a customer, may take longer to validate and may need more time to correct mistakes.
All three factors must be combined.Consider Everything in the Definition of Done
A story point estimate must include everything involved in getting a product backlog item all the way to done. If a team’s definition of done includes creating automated tests to validate the story (and that would be a good idea), the effort to create those tests should be included in the story point estimate.
Story points can be a hard concept to grasp. But the effort to fully understand that points represent effort as impacted by the amount of work, the complexity of the work and any risk or uncertainty in the work will be worth it.
People who know me well might be surprised to learn I’ve accepted full-time employment. I’m sort of an independent-minded person. So, here’s why. (It’s characteristically long-winded, so skip it if you wish.)Backstory
In 2002, I was working as an enterprise architect at a mid-to-large-ish financial services holding company that operated banks, mortgage lenders, investment firms, and so forth. That was my 25th year in the information technology field.
I had reached such a point of frustration with the growing bureaucracy of IT organizations that my wife and I were looking into alternatives, like franchise businesses (Main Event, etc.).
Then a colleague at the company approached me. He said he knew I was on the way out the door, and asked me if I would be willing to work with him on one last thing before I changed careers. He wanted to assess the cost and value of the IT function of the enterprise, and then, based on lessons learned, see what could be done to improve it. I agreed.Within a few months our small group had learned:
- The main problem was the existence of functional silos with numerous cross-dependencies. These dependencies caused so much delay that the organization might be likened to a set of interlocking gears so arranged that they couldn’t turn.
- Every January, the department launched 300 projects at the same time. Staff spent the next seven to eight months waiting to see which ones would crash and burn. Then they scrambled to complete the surviving projects before the December code freeze. January through August was “endless meetings season.” September and October was “death march season.” Then the annual code freeze. Time to recover before the next January.
- The cost of going through the formal bureaucratic process to request services from the IT department was so high that line-of-business leaders didn’t even bother to request things they wanted. Besides, if they requested something they couldn’t be sure it would ever materialize.
- Individual contributors had no idea of the context of their work. From their point of view, there was no coherent activity in the IT department; everything was just a series of disconnected requests for small tasks (add an index on this database table; open such-and-such a port on this internal router; add a field to this COBOL copybook; etc.).
- No one ever received any feedback about the downstream impact of their work. Were the architectural designs sound, or did people have to revamp them? Was the code okay, or did operations have to mess with it to get it installed? Did customers like the user experience, or was it horrid?
In today’s terms, you’ll recognize some of those symptoms as high WIP, dependencies, context-switching, overloaded queues, big-bang delivery, and matrixed organizations.
It was during this effort that we discovered the Agile Manifesto. We recognized in it the same values we were seeking. We reasoned that if there were enough people out in the world who were thinking along the same lines to have published such a document, then someone out there must know how to do this stuff. We looked for help and found ThoughtWorks. We went from there.
I said at the time that if “this stuff” didn’t stick, and the industry reverted to the status quo ante, I would bail. There are other ways to make a living besides the slow death of bureaucracy. I began my Agile journey with one foot out the door. In some ways this has been a Good Thing; it has kept me actively focused on value every day.
Did I bail? No: 2016 is my 39th year in the information technology field.Here we go again
Ah, but there’s trouble in River City. Today, Agile seems to be all about peddling frameworks. You can become certified to teach a framework certification class by passing a framework certification class. It isn’t necessary to have worked in the IT field at all, let alone to understand how Agile thinking can apply to enterprise IT. There are some 400,000 Certified Scrum Masters, only a few of whom have ever written a line of code, worked as a tester, in operations, or in production support.
Some frameworks are meant for scaling team-level Agile methods. They operate by re-introducing traditional governance methods, and killing agility in the process. (See “Every Agile Scaling Framework in the World“)
Other frameworks are meant for de-scaling the organization. They operate by insisting upon radical structural changes on Day One; changes that are impractical in most cases.
The alternative, Kanban, (as defined by Lean Kanban Inc.) is a business organized around selling training courses. It’s more realistic and practical than any of the Agile frameworks, and yet it stops short of providing concrete guidance to clients. The approach is to train leaders (and coaches) and then let them chart their own path forward. Change their thinking, and then get out of their way. Not a bad approach, actually, but it may not go quite far enough.
Agile conferences are 99% about playing board games, sticking notes on the walls, bending pipe-cleaners, and constructing things with little plastic building blocks; and 1% about addressing business needs through Agile thinking or advancing technical excellence through sound software engineering practices.
Agile consultancies that used to help clients solve problems and achieve goals have devolved into sales organizations for “frameworks.” It’s easy money. I know a number of people involved, and they know better than to do this. It really hurts my heart to see them selling their ethics this way. I guess that sounds maudlin, but at least it’s sincere.
Maudlin or not, I’m far from alone in this assessment of the state of Agile.
Four members of the ScrumAlliance board resigned within two months of the date I wrote this. They gave generic reasons, but two of them mentioned that the organization was going in a direction inconsistent with the values expressed in the Agile Manifesto. (I don’t know how long this link will remain valid, but here’s their letter of resignation.)
More than a few people are disappointed with the way things have been going. Here’s an excerpt from a piece by James Grenning on Quora.
Being one of the people that participated in the creation of the Agile Manifesto, I find myself very disappointed by the reaction of engineers to the question “Are you practicing Agile?” Their shoulders drop. They tell me agile is horrible. I ask why. Reasons that stand out are:
- We’re being micromanaged
- The pressure is constantly on for every two week deliveries so quality suffers
- All they care about is the date
Unfortunately, none of those activities are part of Agile, though I can see how it comes to be. The usual starting point is one of mistrust (note they above). Then you get a Scrum Master with two-days of training and pressure for two week deliveries; engineers will get the idea they are the Scrum Slaves.
Another of the Manifesto’s authors, Ron Jeffries, has had occasion to question the direction in which the ideas have been taken. Here’s an excerpt from an article on his site entitled “What I wish we had done…“.
As a faithful reader, you’re probably aware that I believe that the word “Agile” should mean “consistent with the Agile Manifesto”. And, of course, it doesn’t mean that at all. Instead it means whatever the word’s user means at that moment. There’s great confusion as a result. Ah, well, life is tough, then you die. Quickly, I hope, but not soon. But I digress…
An important contributor to the confusion is the proliferation of branded or named methods and frameworks. At the time of the Manifesto, if I recall, there were Scrum, XP, Crystal, and DSDM. Anyway right around that time, Jim Highsmith came out with Adaptive Software Development, Mike Beedle began a series of names like XP@Scrum, and it went on and on. It continues to this day.
…Point is, there are a lot of them. I don’t think we really need a “method” at all. I feel quite sure we don’t need a dozen…
Dave Thomas wrote, in a 2014 piece entitled, “Time to Kill Agile”.
The word “agile” has been subverted to the point where it is effectively meaningless, and what passes for an agile community seems to be largely an arena for consultants and vendors to hawk services and products.
Another Manifesto author, Brian Marick, has recently reanimated his 2009 idea, “Artisanal Retro-Futurism Crossed With Team-Level Anarcho-Syndicalism.” The name is designed to be descriptive of the underlying concept while simultaneously hard for people to cargo-cult. It’s intentionally non-catchy. The catchiness of the word “agile” has backfired.
Those comments come from authors of the Agile Manifesto. They aren’t alone. There’s a lot of disillusionment going around these days. I sympathize. Sometimes it feels as if the entire Agile movement is going in a direction inconsistent with the values expressed in the Agile Manifesto.
The whole thing with “scaling frameworks” has gotten totally out of hand. On a recent subcontracting engagement, I was tasked with helping the prime contractor’s client adopt the Scaled Agile Framework, a.k.a. SAFe. It didn’t take long to observe that the framework was a poor fit for the organization’s transformation goals. They were wasting massive amounts of time, effort, and money on it. But I couldn’t say so, as the prime contractor was pushing SAFe to the exclusion of any other ideas or approaches; and they were only pushing the outward appearance of compliance with SAFe’s “rules.” They were doing nothing of substance. I didn’t last long on that engagement, and that’s okay with me. It made me feel soiled.
That’s not an isolated example, or an aberration. It’s the norm when it comes to companies trying to adopt one “scaling framework” or another. It’s all about the “rules.” There’s no attempt to learn to think in a “lean” or “agile” way. And middleman companies are all too eager to stand under the rain of cash, arms wide and mouths agape, soaking up the profits. People who know better are hawking frameworks like stereotypical used car salesmen. Ethics, anyone?
By January of 2016, I had one foot out the door…again. The reason for the long gap since my last contract is that I’ve been taking a real estate training course, to become a licensed real estate agent. “This stuff” didn’t stick. Time to leave.Enter LeadingAgile
Then a colleague in the Agile community approached me. He said, hey, before you leave, take a look at this. He pointed me to his company’s website: leadingagile.com.
Within a couple of months I learned:
- There are still people in the Agile community who are genuinely interested in helping clients solve problems and achieve goals.
- There are people in the Agile community who understand an established company can’t abruptly restructure itself and “go agile.”
- There are people in the Agile community who recognize the value of a framework when it adds value, but who do not “push” a framework.
- There are people in the Agile community who have a realistic model of organizational transformation, a way to craft a practical roadmap tailored to a client’s situation, and the willingness to guide the client along a path to improvement over the long term.
Many of those people work at LeadingAgile.
LeadingAgile has a very pragmatic and results-focused approach to organizational transformation. Some people think the word pragmatic implies backing off from Agile principles; actually, it means something like practical and realistic. Moving an organization toward business agility means defining a rational system of delivery built around teams. It means paying attention to flow, by which we mean the flow of value, not just “busyness.” Ideas from Lean Thinking are key to the approach, including high visibility and paying close attention to delivery rate and, by implication, anything that impedes value flow or delivery. This practical-mindedness has great appeal for me.
I discovered several people I knew were working at LeadingAgile. Some I had worked with in the past. Some I knew through Agile community events. Some I knew through their work. Mike Cottmeyer, Dennis Stevens, Chris Beale, Tom Churchwell, Rachel Howard, Derek Huether. A who’s who. An all-star team.
For me, then, joining LeadingAgile is like coming home. Home to people I know, whose views about Agile are aligned with my own, and whom I respect professionally and personally. Home to the core values of Agile, which have become so watered down and corrupt over the years.
Now, if “this stuff” doesn’t stick…
And thanks everyone for the Emma greeting, that sure made an 8 year girl very happy
(Emma was supposed to join me on this trip, but couldn’t make it because I had missed some required paperwork for travelling with minors to South Africa).
Here we are in the dog days of summer, but that doesn’t mean we’re taking a break! In fact, we’ve been working hard to help dev teams ship with confidence. So, with that—here are the biggest updates you need to know about.More Security with Azure Active Directory
“What this does, aside from make it easier for an end user to log in, is add an extra layer of security,” says Jonathan Silva, Customer Success Manager at Axosoft.
The idea is to provide a single sign-in process for all users in an organization rather than requiring each person to remember and record their Axosoft credentials with their IT team.
“Having the ability to use Azure Active Directory to log into Axosoft is a huge benefit to users and their IT departments,” adds Dustin Tatgenhorst, Director of IT.For IT, it removes yet another silo of user data and credentials to be managed. This allows end users to securely access the already-existing centralized user database in Active Directory, from anywhere in the world.Dustin Tatgenhorst, Director of IT
Previous to this release, this option was available for those clients who chose an installed solution. Now, hosted users can benefit from it as well.
“So, now when an end user sits down at their desk in the morning and logs into the computer, their credentials are simply passed through to Axosoft. The single sign in allows them to go right into Axosoft seamlessly,” says Silva.
Tatgenhorst agrees. “For your users, it’s one less password to remember, and it allows them to continue using the same credentials they use every day at work,” he says.
In short, it’s less administrative overhead and a better end-user experience. Win-win!Configuration
As an additional offering to the Axosoft Premium plan, organizations can easily configure their Axosoft account by going to:
Tools / Manage Extensions /External Login
Next, you need to update each user to use Azure ID login from:
Tools/ People/ Users > Edit/ General Information
Now, when you access your hosted account login page, you will see the option to use Azure login.
We’ve updated the search functionality in all field templates; this is a small, yet mighty quality of life update! Instead of searching through a list and choosing what you were looking for, you can now start typing and Axosoft will begin to autofill what you need.The new feature of making all the dropdowns and multi-select fields searchable, makes life easier and saves time.Ashley Maberry, Axosoft Developer
If you are in a customer field, just start typing the first couple letters of a client’s name; Axosoft will fill in the rest and give you what you’re looking for.
“Instead of having to look through a large list for what you want, you can simply start typing and your options will be simplified. Finding what you want is just easier overall that way. Originally we were only going to do the ‘Project and Release’ fields since those tend to get large for a lot of companies over time. But once our support team started using it, they were hooked, and they requested other fields be searchable as well,” says Maberry.
For more in-depth information about this release, check out our version history.