Skip to content

Latest commit

 

History

History
1217 lines (660 loc) · 62.7 KB

Learning_Agile_by_Stellman.md

File metadata and controls

1217 lines (660 loc) · 62.7 KB
Raw

Learning Agile by Stellman

Book: Learning Agile: Understanding Scrum, XP, Lean, and Kanban by Andrew Stellman

Chapter 6: XP and Embracing Change

There are 13 primary XP practices that can be grouped into 4 categories. Unlike Scrum they are specific to programming.

  1. Team
  2. Planning
    1. Adopts the same practices from Scrum
      1. "Once the planning is done, the team spends the first part of the iteration writing automated tests for the stories and tasks, and the rest of the iteration writing code to make the tests pass."
    2. Quarterly Cycle
      1. "Once a quarter, the team meets to take a look at the big picture. XP teams will talk about themes, or larger ideas in the real world that they can use to tie their project’s stories together."
        1. Sounds exactly like agile release planning
    3. Slack
      1. "This practice has the team add minor, lower-priority stories to each weekly cycle. These stories are broken down into tasks during the planning meeting, but those tasks are left for the end of the iteration. That way, if the team runs into unexpected problems, it’s very easy for them to cut out those “slack” stories and still deliver complete, working software at the end of the cycle"
  3. Programming
    1. TDD (unit tests)
      1. Short circuits QA handoff patten because testing has already begun
      2. Short circuits low level QA's because they are in fact specialized engineers
      3. Short circuits long regression times through automation
    2. Pair programming
      1. Short circuits code reviews because two eyes have been on it already
  4. Integration
    1. The 10-minute build rule
    2. Continuous Integration (CI)

June 18-19, 2020 (Thur - Fri)

Preparation for and delivery of Get Smarter talk on Becoming a Distributed Organization

June 17, 2020 (Wednesday)

See the following paper on they do it: “Scrum Metrics for Hyperproductive Teams”

On of the ways they get this way is by being hyper focused. Instead of doing a me-centered daily standup, they do a we-centered standup going through the top priority items, not individual contributors. They ask:

  • What did WE achieve yesterday on Priority 1?
  • What was OUR contribution on Priority 1 worth in Story Points?
  • What is OUR plan for completing Priority 1 today?
  • What, if anything, is blocking US or has the potential to slow US down today?

Strictly speaking, a user story doesn't have to have UI but it does need to be able to provide demonstrable benefit to the user. This benefit may not introduce new UI (that may have been delivered in a previous increment) but it should be able to be demonstrated that the none ui work affected via a ui demo somehow.

The "one throat to choke" is increasingly looking to be at odds with collective commitment.

Letting the team fail (a basic element of coaching):

It's better to introduce practices and then let the results how for them selves. If you are always advocating for agile and the team is not seeing problems solved, they will just see you as a zealot.

Practices without values will not result in incredible change. Why would a team get real serious about stories if they don't value delivering working software every sprint?

"if you don’t get self-organization and collective commitment, you don’t get Scrum." - Ken Schwaber

"Instead of trying to prevent those mistakes, he took advantage of them to create learning experiences for the team." - Stellman, Andrew. Learning Agile (p. 160)

"Let the team fail: Certainly, don’t stand idly by while the team goes careening off a cliff. But do use the dozens of opportunities that arise each sprint to let them fail. Teams that fail together and recover together are much stronger and faster than ones that are protected. And the team may surprise you. The thing you thought was going to harm them may actually work for them. Watch and wait." - Stellman, Andrew. Learning Agile (p. 160)

"Often, teams will bring in a consultant as a mentor because it’s easier for their bosses to listen to someone from outside the company tell them that they need to make changes." - Stellman, Andrew. Learning Agile (p. 161)

June 16, 2020 (Tuesday)

Gold-plating: building unasked for features (bad because it introduces new risk) Gold plating is one of the reason why many features go unused. This is why customer colaboration is so critical.

If you want to know how bas software used to be before agile look at the Standish Group's CHAOS report of the mid 90's. The 2002 study put the figures at 45% features never used and 19% rarely used.

"Working software" is a loaded term. It doesnt just mean that the code runs or works. It means code that actualy helps the user do their job.

Effective agile teams dont have these unused features because the user, in the form of the PO, determine what features get done.

"A user story is a deceptively simple tool. It’s a quick and simple description of a specific way that a user will use the software. Most user stories are between one and four sentences long — most teams have a rule of thumb that a user story has to fit on the front of a 3×5 index card." - Stellman, Andrew. Learning Agile (p. 143). O'Reilly Media. Kindle Edition.

"Many effective agile teams maintain a backlog that consists almost entirely of user stories. Because each user story is simple and written from the user’s perspective, it’s easy for the Product Owner to review the stories with the users and stakeholders in order to figure out which stories are the most valuable." - Stellman, Andrew. Learning Agile (p. 144). O'Reilly Media. Kindle Edition.

Condition of Satisfaction == Acceptance Criteria

"Typically, the conditions of satisfaction can fit on the back of the same 3×5 index card as the user story. The Product Owner usually has a hand in writing the conditions of satisfaction or at least reviews them when they’re written." - Stellman, Andrew. Learning Agile (p. 145). O'Reilly Media. Kindle Edition.

"If you think that we’re looking at a 5-point story, and I think it’s only a 2-point story, we’re probably not disagreeing on how much work is involved — we’re disagreeing on exactly what that story means." - Stellman, Andrew. Learning Agile (p. 148). O'Reilly Media. Kindle Edition.

"Here’s how many teams do this: The team holds the second sprint planning meeting. The Scrum Master starts with the first story, and leads a discussion with the team about exactly what they need to do to build it. Everyone works together to come up with a list of individual tasks that they think will each take no more than a day to complete. Each task is written on a separate card — some teams use different colored cards for stories and their tasks to make it easier to tell them apart — and the story card is grouped together with its task cards. This continues until all stories are planned. If the sprint planning timebox expires before all of the stories are broken down, each unplanned story gets a single task card for a task to plan out the story." - Stellman, Andrew. Learning Agile (p. 153). O'Reilly Media. Kindle Edition.

The above breakdown and delineation of user stories from those things that bneed to be done in order to accomplish them ledns itself very much to subtasks. How can it not? There is no clearer way to communicate the grouping of suborniate activities with their promised story deliverable. In physical form, typicaly another color card would be used to indicate a task vs a story.

Stellman, Andrew. Learning Agile (p. 155) exactly describes the subtask method as it was used with phyical cards. No names were addde to the story, only to the subtasks.

The actual story never get moved into the done colum until the last subtask is done.

So what happens at the end of the sprint?

"The sprint is done when the timebox expires. This means that there might still be story and task cards left in the “To Do” and “In Progress” columns. The stories go back to the product backlog so they can be prioritized in the next sprint planning session,5 but the team can reduce the number of points based on the tasks that remain. The team does not get credit for completing a story until its card and all of its task cards are moved to the “Done” column." - Stellman, Andrew. Learning Agile (p. 157)

Interestign that this is mistakenly seen as core scrum:

"many teams make use of additional tools and techniques, which Cohn termed Generally Accepted Scrum Practices (GASPs). For example, many teams find that their Daily Scrum meetings are more effective when held as a standup meeting, where everyone stands until the meeting is complete. This is not a core Scrum practice, but it’s accepted by many Scrum teams." - Stellman, Andrew. Learning Agile (p. 158). O'Reilly Media. Kindle Edition.

"Collective commitment" is key.

"If you don’t get collective commitment, you don’t get Scrum." - Stellman, Andrew. Learning Agile (p. 141). O'Reilly Media. Kindle Edition.

"as the sprint progresses, they have to keep everyone up to date on all of the changes they discover during their Daily Scrum meetings. This is why it’s valuable (but not required) to have users and stakeholders present in the Daily Scrum — but also why it’s very important that they are only there to observe, and not to interfere." - Stellman, Andrew. Learning Agile (p. 141). O'Reilly Media. Kindle Edition.

June 12, 2020 (Friday)

Good Communication Traits:

  • Takes responsibility
  • Respond non defensively
  • Not easily threatened
  • Build Mutual success
  • Seeks solutions
  • Uses persuasion
  • Turn but not rigid
  • Thanks both short-term and long-term
  • Considers others points of view
  • Welcomes feedback
  • Considers conflict to be natural
  • Speak calmly and directly about difficult issues
  • Accept responsibility
  • Seeks excellence

Bad Communication Traits:

  • When's others
  • Response defensively
  • Feels threatened and wronged
  • Triggers defensiveness
  • Holds grudges
  • Shame blame and accusations
  • Binary thinking
  • Short-term advantage
  • Feels victimized
  • Doesn't seek feedback
  • Must win at any cost
  • Is rigid and reactive
  • Create a climate of antagonism
  • Disapproval and contempt
  • Sees others as the enemy
  • Does not listen effectively

Collaboration is huge. It’s part of the agile principles (over contract negotiation)

Osmotic communication (picking up background chatter)

Tacit knowledge (https://commoncog.com/blog/tacit-knowledge-is-a-real-thing/)

June 10, 2020 (Wednesday)

Four Values of Agile:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

  1. Individuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. 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.

The three Pillars of Scrum:

  1. Transparency
  2. Inspection
  3. Adaptation

The five Scrum values:

  1. Courage
  2. Commitment
  3. Respect
  4. Focus
  5. Openness

Twelve Principles of Agile

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need,and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity--the art of maximizing the amount of work not done--is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

**June 8, 2020 **(Monday)

Feature vs component teams and a mixed model. Seems that a mixed approach is ideal: https://www.scaledagileframework.com/features-and-components/

Scrum assumes CD: https://continuousdelivery.com/

Release planning was removed from the Scrum guide: https://www.scrum.org/resources/gone-are-release-planning-and-release-turndown

May 26, 2020 (Tuesday)

What is the value of each new release that’s delivered at the end of each sprint?

“[it] significantly lowers the risk of integration because it keeps the team from waiting until the end of the project to integrate features built by different people, only to discover that those features didn’t quite work together.” - Stellman, Andrew. Learning Agile (p. 121)

“Effective Scrum teams make decisions at the last responsible moment so that they can leave their options open, making it easier to adapt to changes.” - Stellman, Andrew. Learning Agile (p. 118)

**May, 19, 2020 **(Tuesday)

Stakeholder Management (the flow):

  1. Working with project stakeholders
    1. Engage and Empower business stakeholders
    2. Share information frequently with all stakeholders
    3. Form working agreements for participation
    4. Assess organizational changes to maintain a stakeholder engagement
    5. Use collaborative decision-making in conflict resolution
  2. Establishing a shared vision
  3. Creating collaboration
  4. Communicating with project stakeholders
  5. Using interpersonal skills

Some key terms to explore:

  • Gulf of evaluation: In computer science, the gulf of evaluation is the degree to which the system or artifact provides representations that can be directly perceived and interpreted in terms of the expectations and intentions of the user.
  • NPV (Net present value): Net present value (NPV) is the difference between the present value of cash inflows and the present value of cash outflows over a period of time.
  • IRR (Internal rate of return): By contrast, the internal rate of return (IRR) is a calculation used to estimate the profitability of potential investments.
  • EVM (Earned value management) and EVA (Earned value analysis)
  • CPI (cost performance index): a measure of the financial effectiveness and efficiency of a project. It represents the amount of completed work for every unit of cost spent. As a ratio it is calculated by dividing the budgeted cost of work completed, or earned value, by the actual cost of the work performed.
  • Kano model: delighters and exciters

Managing risk in an agile project:

  • Risk in an agile project is anything that threatens the Project's goals
  • Risk is considered an auntie value
  • Risk must be managed in a project
  • Risk identification is an iterative activity
  • Risk is recorded in a risk log

Value driven delivery is the highest weighted section on this certification and yet we are focusing on time in the office?

Graduated fixed-price contract:

  • Both parties share some of the risk and reward
  • If a vendor delivers on time they get paid for their work at the hourly rate
  • If the vendor delivers early they get paid for their work but at a higher hourly rate
  • If a vendor delivers late they get paid for their work but at a lower hourly rate
  • The above is PRIMED for smart contract use

Agile constraints and contracts:

  • Agile is flexible but contracts are not (explicit agile is a contract of sorts because all agreement is a contract)
  • Contracts are a form of a constraint
  • Contracts are constrained by an offer an a proposal
  • Collaboration over contracts
  • Agile projects constrain time and cost
  • Agile projects allow the scope to change
  • Contracts typically constrain and balance time, cost, and scope.
  • Solution: just treat scope as a service.

Contracting in Agile Projects:

  • Request for proposal and agile (basicly a method for interfacing with external orgs)

Five focusing steps of Goldratt’s theory of constraints:

  1. Identify the constraint
  2. Exploit the constraint
  3. Subordinate all other processes to exploit the constraint
  4. If after steps 2 and 3 are done more capacity is needed to meet demand, elevate the constraint
  5. If the constraint has not moved, go back to step one

Bottlenecks and the theory of constraints:

  • A constraint is anything that limits your options
  • Time, cost, and scope are typical constraints
  • A constraint could be the current throughput capacity of the team

Agile Tooling:

  • Preference for low-tech high-touch tools that don't exclude the less technical.
  • Examples:
    • Cards
    • Charts
    • Tools that promote communication/collaboration
    • Tools that promote learning and knowledge transfer

Incremental delivery:

  • Minimal marketable feature (MMF) ← See MMF and incorporate into your system
    • This would lend itself to the feature-as-atomic-unit-of-value theory.

May 18, 2020 (Monday)

Prioritization Schemes:

  • high/med/low
  • MoSCoW
  • Monopoly money
  • 100 point method
  • Dot voting or multi voting
  • Kano Analysis
    • Delighters/exciters
    • Satisfiers
    • Dissatifiers
    • indifferent

May 16, 2020

See: earned value management

Leadership tasks:

  • give transparency through visualization
  • Create a safe environment for experimentation
  • Experiment with new techniques and processes
  • Share knowledge through collaboration

Agile leadership practices:

  • honesty
  • Forward looking
  • Competent
  • Inspiring

12 principles for agile leadership:

  1. Learn team members needs
  2. Learn the project requirements
  3. Act for the simultaneous welfare of the team and project
  4. Create an environment of functional accountability
  5. Have a vision for the created project
  6. Use the product vision to drive your behavior
  7. Serve as the central figure in successful project team development
  8. Recognize team conflict as a positive step
  9. Manage with an eye towards ethics
  10. Remember that is not an afterthought but an integral part of our thinking
  11. Take time to reflect on the project
  12. Develope the trick of thinking backwards

Management vs leadership:

Management is about getting things done while leadership is about getting people to want to do things.

Product visions —> product roadmap

Also see:

  1. Dynamic systems development method
  2. Crystal

Lean 7 core concepts:

  • eliminate waste
  • Empower the team
  • Deliver fast
  • Optimize the whole
  • Build quality in
  • Defer decisions
  • Amplify learning

Lean 7 core wastes:

  • Partially done work
  • Extra processes
  • Extra features
  • Task switching
  • Waiting
  • Motion
  • Defects

5 principles of Kanban:

  • visualize workflow
  • Limit wip
  • Manage flow
  • Make process policies explicit
  • Improve collaboration

Kanban is a pull system

See little's law: duration of cue is proportional to its size

May 15, 2020

All three concepts imply each other:

  • Users
  • Product
  • Features

May 11, 2020

Too much of what we are doing is CYA (cover-your-ass). The points are not the thing we should be worrying about.

See: https://www.frontrowagile.com/blog/posts/102-linguistics-in-agile

A good first step in introducing agile to your company is to talk about the values, and how they might impact your company’s culture. If you find that your agile adoption runs into trouble, finding the mismatch between agile values and company culture can help you smooth out the transition” - Stellman, Andrew. Learning Agile (p. 104).

A “new” wave approach:

  1. We are not getting astonishing results with our Agile
  2. Explicit and publicised sprint goal.
  3. Leverage subtasks to track dev tasks that roll up to an actual real story (estimates and dependency planning)
  4. Team members freely cut tasks for team visibility (not points).
  5. No more “yesterday/today” standups. How are we progressing towards the sprint goal?
  6. Internal releases are killing us (we will put the app in hands every sprint)

Maximizing the work NOT done:

“When everyone on the team uses the Daily Scrum to limit the amount of planning they do to include only what’s necessary to build the next increment of the software, the whole team starts to recognize it as a valuable tool and use it effectively.” - Stellman, Andrew. Learning Agile (p. 110).

“on effective Scrum teams, the team members don’t just commit to their individual tasks. Every single person feels a genuine commitment to delivering the most valuable software they can to their users and stakeholders. When everyone on the team shares this feeling, and agrees to deliver working software at the end of each sprint, we say that the team has made a collective commitment.”

“Planning is necessary. Taking planning out of the hands of the team isn’t. When the Scrum Master breaks down the work for a sprint by himself, goes and gets estimates from the team, assigns work to them, and checks up on their status, he’s acting like the “keeper” of the plan. He’s also encouraging them to be chickens instead of pigs.” - Stellman, Andrew. Learning Agile (p. 99).

Retro action items added to backlog:

"The Scrum Master takes note of any improvements, and specific items (such as setting up a new build server, adopting a new programming practice, or changing the office layout) are added to the product backlog as nonfunctional items.”

For demos:

“The team can only present functional, working software, not intermediate items like architecture diagrams, database schemas, functional specs, etc.” - Stellman, Andrew. Learning Agile (p. 91).

Notice there is a distinction between the backlog (capabilities) and the individual tasks that are required to be done in order to get those new capabilities operational:

“This first part is timeboxed (for a 30-day sprint it’s timeboxed to four hours; for shorter sprints, it’s proportionately shorter) so at the end the team takes whatever they’ve come up with so far and uses that as the sprint backlog. In the second part of the meeting, the team members (with the Product Owner’s help) figure out the individual tasks they’ll use to actually implement those items.” - Stellman, Andrew. Learning Agile (p. 89).

Adding to the sprint backlog is not a big deal but having an inaccurate sprint board is a big deal:

“And if they find that they’ll run out of work before the sprint ends, they can add more items to the sprint backlog. The team must keep the sprint backlog up to date and visible to everyone.”

Also:

“When you’re working on a Scrum team, everyone else on the team should always be aware of what you’re working on and how it moves the project toward its current goals.”

“For Scrum to work, the team has to deeply and viscerally understand collective commitment and self-organization. Scrum’s theory, practices, and rules are easy to grasp intellectually. But until a group of individuals has made a collective commitment to deliver something tangible in a fixed amount of time, those individuals probably don’t get Scrum.” - Stellman, Andrew. Learning Agile (p. 89).

The board game Othello has the slogan, “A minute to learn, a lifetime to master.” This applies really well to a team that’s learning Scrum.

Beginning of chapter 4 is the shortest description of Scrum ever. Could use it as template for DAO.

May 8, 2020

“Grand principles that generate no action are mere vapor. Conversely, specific practices in the absence of guiding principles are often inappropriately used.” - Jim Highsmith

The most destructive thing you can do to your project is to build new code, and then build more code that depends on it, and then still more code that depends on that, leading to that painfully familiar domino effect of cascading changes...and eventually leaving you with an unmaintainable mess of spaghetti code. - Stellman, Andrew. Learning Agile (p. 79)

If a feature is not valuable, it’s often cheaper for the company in the long run to not build it at all, because the cost of maintaining the additional code is actually higher than the value it delivers to the company. When teams write code, they can keep their software designs simple by creating software designs based on small, self-contained units (like classes, modules, services, etc.) that do only one thing; this helps avoid the domino effect. - Stellman, Andrew. Learning Agile (p. 79)

May 5, 2020

Principle #10: Simplicity — the Art of Maximizing the Amount of Work Not Done — Is essential

Code as liability.

The sprint demo is the real moment of truth, not release reports: “Working software is better than progress reports for giving everyone the latest update on the project’s status, because it’s the most effective way for the team to communicate what they’ve accomplished.”

This is a direct consequence of Principle #7: Working Software Is the Primary Measure of Progress.

“Projects run best when everyone in the company recognizes that the team is building valuable software, and when everyone on the team — including the product owner — understands what makes the software valuable to the company.” Stellman, Andrew. Learning Agile (p. 70).

Unfortunately, this is not the case.

Value based delivery: “Ultimately, everyone’s performance should be based on what the team delivers, rather than the specific role that they played in it.”

The value proposition of co-location is inversely related to the amount of documentation needed: “When the team relies more on face-to-face communication, and only uses the minimal amount of documentation needed to build the project, it’s easier for everyone to stay in sync with each other.”

It’s a wild idea that more is, in fact, less: “Overly comprehensive documentation increases the risk of ambiguity, misunderstanding, and miscommunication between team members.”

May 4, 2020

The “motivated individuals” of principle six makes me believe that being agile can not merely be a ‘process’ because it starts with motivated individuals. If those individuals are not present then it’s a non starter.

April 29, 2020

Principle #6: Build Projects Around Motivated Individuals. Give Them the Environment and Support They Need, and Trust Them to Get the Job Done.

“Projects run best when everyone in the company recognizes that the team is building valuable software, and when everyone on the team — including the product owner — understands what makes the software valuable to the company.”

Do I or anyone else see the value of what we are building? I don’t know anything about MyChart and our budget is often called “funny money” so it seems like there is a breakdown in driving forces here. Is MyUPMC just an expensive ego project for UPMC.

Just compare the apps in the Play store:

Principle #5: Businesspeople and Developers Must Work Together Daily Throughout the Project.

“To build software well, teams need to have a lot of face-to-face discussion with businesspeople, because they need to tap into their knowledge of the company’s problems that are going to be solved with software. The businesspeople got that knowledge by solving those same problems without software. So for most businesspeople who work with software teams, the software project is typically a small part of their job.” Stellman, Andrew. Learning Agile (p. 68).

See the growth from domain knowledge to manual processes to automation with software? If the gap from business person to engineer could be closed the efficiency of this process would be drastically improved. Hence the “NoCode” movement.

“That’s a big distinction between an agile team and a traditional team. The traditional team treats the business user as a customer to be negotiated with; the agile team collaborates with the customer (typically the product owner) as someone with an equal say in the way the project is run. (That gets back to the core agile value of customer collaboration over contract negotiation!)”

Principle #4: The Most Efficient and Effective Method of Conveying Information To and Within a Development Team Is Face-To-Face Conversation.

How does this jive with remote first organizations?

“When a group of people look at the world the same way, and communicate about both positive and negative ideas openly, they end up with a shared perspective. When a change comes along that requires rethinking, the team members don’t have to explain as much to each other.”

This shared world view is caught, not taught. It's like when you can tell if someone is really in the NA fellowship or not or from another fellowship. You can just tell and it usualy has to do with unwriten or “undocumented” things they say or do.

“Any one piece of documentation is always written from the perspective of a person in a specific role: business analysts write requirements from one perspective, architects build designs from another, and QA engineers create test plans from a third. Then, when they need to tie these all together with traceability matrices, they discover exactly the kinds of inconsistencies that you’d expect these fractured perspectives to introduce. Building the documentation becomes a goal unto itself, and requires an increasing amount of up-front effort. And when a change finally does happen, all of that work that they put into reconciling their perspectives into a single comprehensive set of documentation needs to be redone. This causes the team to spin their wheels rewriting documentation, rebuilding traceability matrices, and resolving conflicts when they should be writing code, testing the software, and deploying the change. There’s got to be a more efficient way to build software.” - Stellman, Andrew. Learning Agile (p. 66)

Perspectivalism at work.

“how much documentation should [a team] create? The answer, for an agile team, is just enough to build the project...But if, for example, a team finds that it really helps them to write a functional requirements document, then they can do it and still be agile. It all depends on what works best for the team, and that’s one of the freedoms that agile gives you.” - Stellman, Andrew. Learning Agile (p. 65)

It's always a means to an end.

April 28, 2020

The 12 Principles of Agile Software

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
    1. making all the necessary changes along the way.
    2. The downside to delivering early is that the software that’s first delivered to the customers is far from complete.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. 3. We stop thinking of changes as mistakes. We did our best with the information we had at the time, and it only became clear that we were wrong because the decisions we made along the way gave us the perspective to recognize the changes that we have to make today.
    4. We learn from the changes. This is the most effective way for a team to grow and get better at building software together.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  5. Businesspeople and developers must work​ together daily throughout the project.
  6. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity — the art of maximizing the amount of work not done — is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

April 27, 2020

  1. Individuals and interactions over processes and tools
    1. People can go wrong when they blindly follow a process. A great tool can sometimes help you do the wrong thing faster. Before you’re able to implement a process, even if it logically makes a lot of sense or is rationally the right thing to do, you need to sell it to the people who are working with you. If people don’t get why you’re doing what you’re doing, all they’ll see is that you’re asking for an arbitrary change. “Even user stories themselves are less important than the fact that they help the team have a conversation about what the story means.”
  2. Working software over comprehensive documentation 2. To an agile practitioner, working software is software that adds value to the organization. Documentation is only a means toward that end. ..the team can often take a novel approach to documentation that allows it to be embedded in the software itself. For example, one such agile practice is test-driven development..it serves as documentation, because it gives developers a record of what the code is supposed to do.
  3. Customer collaboration over contract negotiation 3. A developer who is constantly trying to protect himself will be less able to try new ways to collaborate and innovate with the people who need to use the software being built. One way agile teams put this value in place is to have a product owner who is a real, first-class member of the team. She may not be actively developing code, but she does attend meetings, contribute ideas, and, most importantly, feel ownership for the final product.
  4. Responding to change over following a plan 4. IF [the project manager] values following a plan over responding to the change, he might dig his heels in.
  5. That is, while there is value in the items on the right, we value the items on the left more.

Understanding and effectively working with agile starts with understanding these values.

Stellman, Andrew. Learning Agile

April 26, 2020

I took an “Agile” quiz on LinkedIn last night and failed it. I am feeling very embarrassed by it as I thought I was shaping up to know a few things. So, starting immediately, I’m starting a reading and study plan so I can know I’m really progressing in my craft. Notes will start here in this document. Newest at the top.

Agile is an umbrella term covering Scrum, Kanban, Lean, and XP.

Almost used synonymously with Scrum tho.

Scrum

Scrum is, first and foremost, a managerial framework. It's about things developers do when they're not writing code.

Values:

  1. Commitment (to goals in the Sprint).
  2. Courage (to do what you think is right).
  3. Focus (on the work items in the current Sprint).
  4. Openness (about any challenges you face).
  5. Respect (trust that everyone is doing their best).

Kanban

Invented by a Toyota engineer Taiichi Ohno in the late 1940s.

Principles:

  1. Focus - reduce multitasking.
  2. Decrease waste.
  3. Customer needs come first (i.e. their business needs - ROI).

Practices:

  1. Visualization.
  2. Limiting work in progress.
  3. Flow management (can be done either by managing queues or by limiting work in progress).
  4. Making policies explicit.
  5. Using feedback loops.
  6. Experimental evolution.

Lean Software Development

Armed with a poorly-translated copy of the book written by a Toyota manager, Mary Poppendieck co-authored the book, Lean Software Development, with her husband about applying Kanban in the 80’s.

Principles:

  1. Eliminate waste.
  2. Amplify learning.
  3. Decide as late as possible.
  4. Deliver as fast as possible.
  5. Empower the team.
  6. Build integrity in.
  7. See the whole.

Practices:

  1. Seeing waste.
  2. Value stream mapping.
  3. Set-based development.
  4. Pull systems.
  5. Queuing theory.
  6. Motivation.
  7. Measurements.
  8. TDD (also pertains to Toyota’s stop-the-line philosophy of uprooting flaws early on).

XP - Extreme Programming

Extreme programming started as an experiment by Kent Beck, who was working for Chrysler at the time. The idea was to take cherry-picked programming practices to the extreme and see what happens.

XP offers an algorithm for process management.

Focus on writing the code you need today instead of thinking about tomorrow, next month, etc. This is called the YAGNI (You Aren't Gonna Need It) approach.

Practices:

  1. Planning game.
  2. Test-driven development ("write unit tests first").
  3. Pair programming.
  4. Whole team (customer/actual user of the program is available for feedback).
  5. Continuous integration.
  6. Refactoring of design improvements.
  7. Small releases.
  8. Coding standards.
  9. Collective code ownership.
  10. Simple design.
  11. System metaphor (naming things in a way that programmers, customers, and everyone else understands).
  12. Sustainable pace (no overtime).

Conway's Law:

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. - Melvyn Conway, 1967

Brooks' Law:

An observation about software project management according to which "adding human resources to a late software project makes it later".

Amazon's notion of the Two Pizza Team (i.e. the whole team can be fed by two pizzas), meaning no more than a dozen people.

Products not Projects

Amazon's notion of "you build, you run it" where a development team takes full responsibility for the software in production.

The microservice community favours an alternative approach: smart endpoints and dumb pipes.

Be of the web, not behind the web. - Ian Robinson

Microservice teams use the principles and protocols that the world wide web (and to a large extent, Unix) is built on.

"YAGNI" or "You Aren't Going To Need It" is an XP principle and exhortation to not add features until you know you need them.

Domain-Driven Design notion of Bounded Context:

Netflix's Simian Army induces failures of services and even datacenters during the working day to test both the application's resilience and monitoring.

Postel's Law states that you should be liberal in what you accept and conservative in what you send. Also referred to as the robustness principle.

Service-oriented architecture (SOA) is a style of software design where services are provided to the other components by application components, through a communication protocol over a network. The basic principles of service-oriented architecture are independent of vendors, products and technologies.[1] A service is a discrete unit of functionality that can be accessed remotely and acted upon and updated independently, such as retrieving a credit card statement online.

Agile Coach

Agile coach mission: Help make the people, teams, and organizations better by unlocking their potential.

What is “better”?: faster time to market, improved quality, happier customers, a happier team, etc

•Provides expertise and leadership for agile teams and product development lifecycles. Effective in driving cultural change and leading transformation. Challenges conventional thinking that interferes with change efforts.

•Ensures team adherence to Agile principles. Provides coaching to the team(s), including the establishment of new teams, and summarizing and promoting best practices.

•Collaborating with team to drive the maturity of agile processes and practices; identify and facilitate continuous improvements.

•Facilitates discussions across multiple levels of stakeholders to identify and escalate highly complex problems impeding teams' delivery/progress.

•Identifying learning and development opportunities for team on the subject of agile methodology, principles and/or tools; customizing, maintaining and delivering training materials as needed.

Competencies :

Manages Risk - Working Experience

•Assesses and effectively manages all of the risks associated with their business objectives and activities to ensure activities are in alignment with the bank's and unit's risk appetite and risk management framework.

Customer Focus - Extensive Experience

•Knowledge of the values and practices that align customer needs and satisfaction as primary considerations in all business decisions, and ability to leverage that information in creating customized customer solutions.

Job Specific Competencies :

Agile Development - Subject Matter Expertise •Knowledge of and ability to utilize formal agile methodologies, disciplines, practices and techniques for the delivery of new and enhanced applications.

Coaching Others - Subject Matter Expertise •Knowledge of coaching concepts and methods; ability to encourage, motivate, and guide individuals or teams in learning and improving effectiveness.

Conflict Management - Extensive Experience •Understanding of how to anticipate, recognize, and deal effectively with existing or potential conflicts at the individual, group, or situation level; ability to apply this understanding appropriately to diverse situations.

Effective Communications - Extensive Experience •Understanding of effective communication concepts, tools and techniques; ability to effectively transmit, receive, and accurately interpret ideas, information, and needs through the application of appropriate communication behaviors.

Group Facilitation - Subject Matter Expertise •Ability to design and facilitate a group process, elicit contributions from group members, stimulate a focused group discussion, and achieve a desired outcome.

Interpersonal Relationships - Subject Matter Expertise •Knowledge of the techniques and the ability to work with a variety of individuals and groups in a constructive and collaborative manner.

Listening - Subject Matter Expertise

•Knowledge of effective listening issues and techniques; ability to gather, clarify, and apply information transmitted verbally, while exhibiting a genuine interest toward the speaker.

Planning and Organizing - Subject Matter Expertise •Mobilizes both time and resources to get things done.

Innovation - Extensive Experience

•Develops new ideas and initiatives that improve the performance of the organization.

Embracing Challenge - Extensive Experience •Knowledge of the issues and opportunities in complex situations; ability to respond positively to difficult problems and eliminate obstacles that face clients and internal teams.

Required Education and Experience :

Roles at this level typically require a university / college degree, with 5+ years of industry-relevant experience. Specific certifications are often required. In lieu of a degree, a comparable combination of education and experience (including military service) may be considered.

The term I will use in the remainder of this book to describe this faithful, functional, and practical long term planning is simply agile planning or quarterly planning

Illustrations: https://www.sketchbubble.com/en/presentation-agile-planning.html

https://monday.com/blog/agile-planning/

https://kanbanize.com/agile/project-management/planning/

http://agilelucero.com/agile/agile-planning-onion/

https://www.productplan.com/agile-planning-onion/

https://www.scrum.org/forum/scrum-forum/32851/sprint-zero

“Agile teams use three levels of planning: release planning, iteration plan- ning, and daily planning. The release plan looks ahead for the duration of the re- lease—typically, three to six months. An iteration plan looks ahead only the duration of one iteration—typically, two to four weeks. A daily plan is the result of team member commitments made to each other in a daily stand-up meeting.” - Agile Estimating and Planning by Mike Cohn

Terms that need to be disambiguated:

Agile Roadmapping:

Release Planning:

https://www.productplan.com/product-roadmap-vs-release-plan/

Capacity planning:

Sprint Zero:

Usually considered a preparatory step to a team's first sprint.

Long term planning in Agile

TOC:

Introduction

Assumptions

Just Another Loop

The Value of Long Term Planning

Characteristics of Agile Roadmapping

Step by Step Roadmapping Session

Parenthetical thoughts on results-based planning:

Results-based Planning

There is an assumption that each iteration is planned with objectives and key results (OKR) in mind. See: Introduction to OKR

Compare KPI’s.

There is a big book too: Measure What Matters by John Doerr

The presupposition to all of these iterations should be impact, not merely delivery:

“The traditional linear roadmap model, one where there is a starting point and clear, feature-specific endpoint (almost always with a fixed date) is outdated. It reflects an output-focused mode of operating a digital business. Instead, today, successful product-led organisations focus on outcomes.”

“Progress on this type of roadmap is not measured in how many features have been delivered or whether they’ve been delivered on time. Instead, progress is measured on how well we’ve changed customer behaviour for the better. If our ideas didn’t drive customer success, we kill those ideas and move on to new ones. The learning drives ideas for future quarterly backlogs.”

Note: disambiguate scrum and agile in the below writing.

Congratulations. You’re a scrum master. A designated ninja in agile methodologies. Maybe you’re just starting down this exciting role or you have been doing this for years. Either way, you represent an important tho ever mysterious role of servant leader and change agent to your organization in general and teams in particular.

Maybe you are in the flow of things and your teams are chugging along through the team stages of forming, storming, and norming. Maybe you are doing all the prescribed ceremonies and work is getting done. Sooner or later someone is bound to ask about long term planning. This book is not about foundational agile basics laid out in the scrum guide. For the most part, it assumes you know and are practicing those things. This is about doing long term planning in that context without betraying everything you believe and are already doing.

What we can do: capacity

What we plan to do: roadmap

Assumptions

You are already doing agile and are familiar with the 5 artifacts and 6 activities and values.

We can review them briefly but the purpose of this work is to really dial in on the specific activity of

You use certain categories to define and organize your work: epics, stories, spikes.

Just Another Loop

There have been numerous attempts to augment scrum in order to make it scale. So many in fact that Deloit, the high profile consulting company created a poster showing many of them overlapping related to their domain of concern and interest. Feel free to google it for yourself and be amazing at how complex things can get. I don’t believe we have to adopt this complexity in order to pursue long term agile planning. Simple is better and if we can get along without multiplying vocabulary, artifacts, and ceremonies then this we should do.

If the story is the atom and the Sprint is the molecule, then the quarter might be thought of as a developmental stage of an organism. You can come up with any number of analogies for this. The important point is the following. All three have a clear definition, business value, and timbox from within which we aim to accomplish them.

In an ideal world, teams should be releasing every sprint, or more, so this could also be called quarterly roadmapping. Because there could be multiple releases done in that period and sprints are already planned so the next logical increment of planning is the quarter.

While it is not necessary, I think roadmapping in quarters makes sense and most delivers what larger organizations are seeing.

Step by Step Roadmapping Session

Prerequisites and/or assumptions:

Design vision

Design the box exercise or pre-write the release notes.

Philosophy:

The team must be of the same understanding that this is not a waterfall a planning activity being shoehorned into the agile process. The PO must understand that things will surely change. As surely as they change from day to day and from sprint to sprint, they will even more so change over the course of the proposed roadmap.

Setup:

The war room. (High touch, low tech.)

Ability to whiteboard and hang things, preferably in a long-lasted way.

Epics listed with designs laid out next to them.

Existing stories represented on the board in color X.

Sticky notes of colors Y and Z on the table representing stories and spikes.

This way they can be added to the board physically by anyone and they are not mixed up with issues already created.

Steps:

Read the feature document for the epic.

Step through the designs.

Everyone add spikes or stories where they think there are holes.

Go through each sticky, if it makes it, that person gets a star next to their name. (Catalogue games)

SWAG estimate each sticky.

List risks

To avoid confusion or conflation of story points, I like to use a seperate term to describe the units of estimations used at the epic level. You can use another term or metric but I simply refer to the estimate is swag estimates and ensure they are only assigned at the epic level. This removes any confusion as to which stories have actually been groomed and which stories have not and possible remain in a merely stubbed form.

Definitions

Compare..

Tricks:

  • Engineering quarantine hrs (Two advantages: less interruption, middle road between story points and ideal days)
  • Engineer effectiveness days (more precise prediction)

Quotes from “Agile Estimating and Planning by Mike Cohn”

Chapter 13: Release Planning Essentials (10 pages)

“Release planning is the process of creating a very high-level plan that covers a period longer than an iteration.”

“At its simplest level, release planning is trivial: Multiply the expected velocity by the number of planned iterations and then select stories whose estimates sum to fill up the release.”

Listed reasons on why a release plan is important:

  1. “..it helps the product owner and the whole team decide how much must be developed and how long that will take before they have a releasable product.”
    1. This assumes an unreleased greenfield project.
  2. “a release plan conveys expectations about what is likely to be devel- oped and in what timeframe. Many organizations need this information because it feeds into other strategic planning activities.” 2. Consistent with roadmapping
  3. “a release plan serves as a guidepost toward which the project team can progress. Without the concept of a release, teams move endlessly from one iteration to the next. A release plan provides context that allows iterations to combine into a satisfying whole.” 3. Prevents death march syndrome

“Part of planning a release is determining how much can be accomplished by what date.

In some cases, we start with a date and see how much can be finished by then.

In other cases, we start with a set of user stories and see how long it will take to develop them.”

“Projects are typically either date-driven or feature-driven.”

  • Cohn touching on scope-vs-date planning

“Naturally, should your project, organization, and work environment warrant it, you can include additional information in a release plan. For example, you may wish to communicate some key assumptions underlying the plan. Most notably, you may want to state assumptions about who is on the team, how long the iterations will be, the date the first iteration will start, and the date the last iteration will finish.”

A good practice to assign specific work to specific iterations thereby setting some sprint goals ahead of time. These can act as checkpoints for the release.

From feature cataloguing to sprint goal checkpoints.

The release plan should be publicly visible and updated after every iteration.

Idea: Conclude all the teaching of the book with an example using a fake company.

Before starting to plan a release:

Before starting to plan a release, it is important to know the criteria by which the project will be evaluated as a success or a failure.

Will the product developed make the desired amount of money?

Will it save enough money?

Will the product capture the target market share?

Quotes from “Agile Estimating and Planning by Mike Cohn”

Chapter 17: Buffering Plans for Uncertainty (12 pages)

“first-level commitments”

“it is useful to include a buffer in the determination of the schedule. A buffer is a margin for error around an estimate. In cases where there is significant uncertainty or the cost of being wrong is significant, including a buffer is wise. The buffer helps protect the project against the impact of the uncertainty. In this way, buffering a project schedule becomes an appropriate risk management strategy. In this chapter, we’ll look at two types of buffers: feature buffers and schedule buffers.”

A feature buffer represents flexibility in scope.

“Creating a feature buffer is simple to do on an agile project. First, the customer selects all of the absolutely mandatory work. The es- timates for that work are summed. This represents the minimum that can be re- leased. The customer then selects another 25% to 40% more work, selecting toward the higher end of the range for projects with more uncertainty or less tolerance for schedule risk. The estimates for this work are added to the original estimate, resulting in a total estimate for the project. The project is then planned as normal for delivery of the entire set of functionality; however, some amount of the work is optional and will be included only if time permits. The optional work is developed last, only after the mandatory work is complete.”

  • Basically the stretch-goal or stepped-MVP method. Also see: DSDM

A schedule buffer is adding time to ensure a drop-dead date is made.

Advocates double pointing all stories to get a range..

“A fea- ture buffer can be constructed by estimating both a 50% likely size and a 90% likely size for each user story. By applying the square root of the sum of the squares formula to each of the 50% and 90% estimates, an appropriately sized schedule buffer can be estimated.”

“The project buffer should represent at least 20% of the total project dura- tion. A smaller buffer may not provide adequate protection for the overall project.”

The safest approach is to use both, thus committing to a range of capabilities delivered on a date that has buffer built in.

“When we allow small amounts of flexibility in both delivery date and functionality, we can buffer two dimensions of the project. More importantly, we buffer each project constraint with the appropriate resource: We buffer the deadline with time; we buffer functionality with functionality.”

Is a schedule buffer just padding?

“A schedule buffer is a necessary margin of safety added to the sum of estimates from which local safety has been removed.”

“On many projects, a precise deadline with a precise set of delivered functionality is not needed. Instead, the team simply needs to deliver high-quality software as fast as possible over a sustained period”

  • One argument for not doing roadmapping at all but, once again, it is valuable to extrapolate out from this pattern of delivery and work backwards from this longer term goal.

Quotes from “Agile Estimating and Planning by Mike Cohn”

Chapter 19: Monitoring the Release Plan (11 pages)

“At the start of a release, we establish a plan that says something like “Over the next four months and eight two-week iterations we will complete approximately 240 story points [or ideal days] of work.”

  • The main pillars that should be communicated at the conclusion of a capacity planning exercise.

“These forces (completed work, changed requirements, and revised esti- mates) can be thought of as being similar to the forces of the wind (called lee- way) and the forces of the sea (called drift) on a boat.”

  • Comparing the changing factors of a project to elements working against a boat at sea.

Two charts discussed:

  • Release burndown chart
  • Release burndown bar-chart

Quotes from “Agile Estimating and Planning by Mike Cohn”

Chapter 22: Why Agile Planning Works (8 pages)

  • Replanning Occurs Frequently (Every iteration)
    • “Knowing that a plan can be revised at the start of the next iteration shifts a team’s focus from creating a perfect plan (an impossible goal) to creating a plan that is useful right now.”
  • Estimates of Size and Duration Are Separated
    • Points vs velocity
  • Plans Are Made at Different Levels
    • “Because agile plans cover three different levels—the release, the iteration, and the current day—each plan can be made with a different level of precision.”
  • Plans are based on features, not tasks
    • “It is easy to plan an entire project using standard tasks without really understanding the product being built. When planning by feature, the team has a much better understanding of the product.”
  • Small Stories Keep Work Flowing
  • Work in Process Is Eliminated Every Iteration
  • Tracking Is at the Team Level
  • Uncertainty Is Acknowledged and Planned For

A Dozen Guidelines for Agile Estimating and Planning from Mike Cohn

  1. Involve the whole team.
  2. Plan at different levels
  3. Keep estimates of size and duration separate by using different units
  4. Express uncertainty in either the functionality or the date
  5. Replan often
  6. Track and communicate progress
  7. Acknowledge the importance of learning
  8. Plan features of the right size
  9. Prioritize features
  10. Base estimates and plans on facts
  11. Leave some slack
  12. Coordinate teams through lookahead planning

Use this book to describe yourself as an Agile Coach.

A landscape of books on the subject is very small: https://www.amazon.com/s?k=agile+release+planning&i=digital-text&ref=nb_sb_noss_1

  1. Catalogue (Review what we have)

  2. Spikes and Stories Cut (Cover what we don’t)

  3. At least 2 Sprints Groomed (124pts)

  4. Epics estimated (Unestimated stories + enumerated risks)

  5. Sprint Zero checklist complete

It’s also useful and relevant as the very name of the agile process called Scrum because through the unpredictable chaos of the rugby team the ball is gradually move from one location to another. Thus the very source of the iterative method called Scrum.

This guy made $400 a month on his ebook and tells all about it:

https://news.ycombinator.com/item?id=22026089