Skip to content

Instantly share code, notes, and snippets.

@daviddias

daviddias/Software Development Process and Managing It - PL Team Week Lisbon 2016.md

Forked from haadcode/Software Development Process and Managing It - PL Team Week Lisbon 2016.md
Created July 17, 2016 16:29
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save daviddias/0216abef5e78ebe0d23bd92d688efdd5 to your computer and use it in GitHub Desktop.
Save daviddias/0216abef5e78ebe0d23bd92d688efdd5 to your computer and use it in GitHub Desktop.
Download ZIP
Software Development Process and Managing It - PL Team Week Lisbon 2016.md
Raw
Software Development Process and Managing It - PL Team Week Lisbon 2016.md

Software Development Process and Managing It

Introduction

  • We're growing in terms of team and the product
  • We're moving from "prototyping" to "production" --> our needs change
  • Need to shift our mindset to "delivering"
  • Need a way to manage all the 1001 endeavours we have

Introduction to Methodologies

Scrum

  • TODO: where does Scrum come from? what does "Scrum" mean?
  • Product is built in a series of fixed-length iterations called sprints
  • Milestones – i.e., the end of a sprint – come frequently, bring a feeling of tangible progress with each cycle
  • Scrum calls for four ceremonies that bring structure to each sprint:
    • Sprint planning
    • Daily stand-up
      • During a sprint, visual artifacts like task boards and burndown charts, visible to the team and spectators alike, are powerful motivators.
    • Sprint demo / Sprint review / Show & Tell
      • Having the opportunity to show off new work at the sprint demo is equally motivating
    • Sprint retrospective
    • Three specific roles:
      • Product owner
      • Scrum master
      • Development team
  • Pros
    • Clear structure to way of working
    • Gives focus for getting things done (fixed length sprints)
    • Strong process for learning from failures (retrospectives and "reset" at the beginning of each cycle)
  • Cons
    • Fixed-length sprints
      • Can be too long for a "startup", they're rigid and it's hard to NOT break the process
    • Rigidness
      • "The faster technology improves in allowing us to quickly build & demo features, the faster it enables the customer to change their thinking, the faster it enables us to learn and adapt, the faster things are changing. And we can either respond to those changes by truly adapting the software into the right solution. Or we can blindly ignore this information and stubbornly continue marching down the not-quite-right-path because our sprint hasn’t ended yet."
    • Roles
  • Further reading

Kanban

  • TODO: where does Kanban come from? what does "Kanban" mean?
  • A kanban team is only focused on the work that's actively in progress
    • Matching the amount of work in progress to the team's capacity
  • Once the team completes a work item, they pluck the next work item off the top of the backlog.
    • "The product owner is free to re-prioritize work in the backlog without disrupting the team, because any changes outside the current work items don't impact the team. As long as the product owner keeps the most important work items on top of the backlog, the development team is assured they are delivering maximum value back to the business. So there's no need for the fixed-length iterations you find in scrum."
  • Cycle time is a key metric for kanban teams.
    • The amount of time it takes for a unit of work to travel through the team’s workflow – from the moment work starts to the moment it ships."
  • It's the entire team's responsibility to ensure work is moving smoothly through the process.
  • As bottlenecks occur, resources are gradually move to bottleneck until it opens
  • Pros:
    • Multitasking kills efficiency --> focus on very small amount of things at a time
    • Flexibility for scheduling
      • As soon as a feature is completed – two things happen:
          1. The feature is available for immediate release into production (should the team wish to do so)
          1. The team can start working on whatever the next highest priority item is. Even if that item was just learned today!
    • TODO: Example Kanban board: http://cdn.hackerchick.com/wp-content/uploads/2012/01/2012-01-Agile-vs-Lean-Kanban-Board6.png
      • Each column represents the state of the feature
      • Under each column – in red – is the maximum number of features that are allowed to exist in that state at any given time
    • Separating the work into a few different states reaps yet more advantages from Kanban:
        1. You can specify different workload capacities for different disciplines based on your team’s capabilities
        1. You get a visual, real-time status of your team’s workflow so you can be continually optimizing your process as well as eliminating bottlenecks (or other problems) as they occur (before they have a chance to compound).
      • The result is more feedback with the ability to adapt to that feedback faster
    • "Rule #3: Once a person starts a task, it can’t change while they’re working on it and they must complete it before beginning the next."
  • Cons:
    • Doesn't provide an immediate "this is when things happens in the future" view
  • Kanban beautifully complements Continuous Delivery
    • "The practice of releasing work to customers frequently–even daily or hourly"
  • https://www.atlassian.com/agile/kanban

Scrum vs. kanban

  • Kanban and scrum share some of the same concepts but have very different approaches.
SCRUM KANBAN
Cadence: Regular fixed length sprints (ie, 2 weeks) Continuous flow
Release: At the end of each sprint if approved by the product owner Continuous delivery or at the team's discretion
Roles: Product owner, scrum master, development team No existing roles. Some teams enlist the help of an agile coach.
Key metrics: Velocity Cycle time
Change philosophy: Teams should strive to not make changes to the sprint forecast during the sprint. Doing so compromises learnings around estimation. Change can happen at any time.

Lean

  • Optimize flow efficiency across the entire value stream "from concept to cash."
  • Set of principles for achieving quality, speed & customer alignment
    • Understanding value
    • Increasing flow efficiency
    • Eliminating errors
    • Learning through feedback
  • Manage product development using the principles of cadence, flow, and pull
  • Relentlessly eliminate anything that isn’t adding value and only work on what we absolutely need to be doing at this moment in time
    • Also means eliminating time spent building what "we know" we’ll need in the future
      • "Things are constantly changing so we often end up not needing them – or if we do, we have to rework them because conditions and our understanding has changed by then"
    • Also means eliminating inefficient ways of working – like multitasking
  • Lean also puts a very strong emphasis on what it calls “the system” – that is, the way that the team operates as a whole
  • Lean says to respect that the people doing the work are the ones that best know how to do it
    • Give them what they need to be effective and then trust them to do it
  • "Develop in a way that builds quality into our product, because there’s no way to continuously deliver fast if we have to keep going back to clean up our messes"
  • Understand that knowledge creation is the essential work of product development
  • Charter a team of responsible experts led by an entrepreneurial (system) designer
  • Lean software development came to focus on:
    • Build the right thing
      • Understand and deliver real value to real customers.
    • Build it fast
      • Dramatically reduce the lead time from customer need to delivered solution
    • Build the thing right
      • Guarantee quality and speed with automated testing, integration and deployment
    • Learn through feedback
      • Evolve the product design based on early and frequent end-to-end feedback
  • Further reading

Programmer Anarchy

  • "Post-Agile development methodology"
  • "... formality and rules are constraining to creativity and productivity"
  • There are no PMs, Iteration Managers, BAs, QAs / testers or “managers of programmers” – all the normal rules of managing software development in a professional environment are gone
  • At the start of the day the programmers choose their own work during daily stand-up meetings
  • Programmers work directly with the customer, which builds more trust and understanding
  • "...that with no managers to give power to their programmers to go ahead and develop (managers “empowering” their teams), programmers go ahead and take total responsibility for the success of each project in a form of self-organised “anarchy”"
  • "...experience of Programmer Anarchy was probably so positive because he was working in a team of high performance programmers, who, like him, could cope with the demands of self-organized development"
    • My experience is the same, high performers love it, others not so much
    • Need a team of experienced and high performing programmers to make it work
    • My experience ended in chaos, with a team that shipped nothing
  • Programmer Anarchy presumes everyone is their own leader, but again not everyone is like that.
    • Lots of people don’t want to take control or drive through the delivery, they just want to do a day job.
  • "The most powerful idea in Programmer Anarchy is the idea that programmers take personal responsibility for the success of each project, the rest of it feels to me like a mix of good intentions, some feel-good Californian vibes and a heavy dash of Marxism."
    • "I think that any kind of team will always need a division of labour, a leadership structure to organize and motivate the team and a support function to allow the core part of the team to focus on doing what they do best.
  • Source: https://martinjeeblog.com/2012/11/20/what-is-programmer-anarchy-and-does-it-have-a-future/

Meditation Driven Development

  • "Tim was a talented developer working in a company filled with talented developers. Pretty much any methodology you care to think of was going to work with these people."
  • "Tim misidentified the source of this productivity as being the result of his methodology, rather than his competence of himself and his team."
  • "People matter in building software. That's the message of this particular fact. Tools matter. Techniques also matter. Process, yet again, matters. But head and shoulders above all those other things that matter are people."
  • "Great developers create great software not because they follow the strictures of some methodology but because they are truly great, gifted artisans."
  • Source: http://www.ckwop.me.uk/Meditation-driven-development.html

What is the best methodology? What "true" Agile and how do you do it "correctly"?

Example

One member in the Crystal family of methodologies is Crystal Clear. Crystal Clear can be described to a Level 3 listener in the following words: “Put 4-6 people in a room with workstations and whiteboards and access to the users. Have them deliver running, tested software to the users every one or two months, and otherwise leave them alone.” I did, in fact, describe Crystal Clear in those words to a savvy project sponsor. He followed those instructions and reported five months later, “We did what you said, and it worked!” I interviewed the team leader some months later and his report was about as short as my instructions: “Following your suggestion, the four of us took over this conference room, which has network connections. We kept it for all four months, drawing on the whiteboards over there, delivering software as we went. It worked great.”

AND

  • There's no ONE process to use,
  • Different team size requires different process and structure

It's about the people

  • "Only when all of the lean principles are implemented together, combined with strong "common sense" with respect to the working environment, is there a basis for success in software development."
  • Focus on Intent, not practices or rigid structures
    • The practices are tools to help us, they’re not what makes us agile
    • Think about what you most want to achieve with agile, and then select some practices that will help you achieve it
      • "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software"
  • "It takes a team of very high quality developers to make a truly Agile methodology work successfully"
    • "You don’t just need a good programmer, you need one with good communication skills, one that understands the business enough to work with it productively and one that is savvy enough about why tactical and strategic decisions are made"

Why agile work - The Principles

  1. Eliminate Waste
    • Add Nothing but Value.
      • Goes for both the code and the process
    • Waste can be:
      • Partially done work
      • Extra processes
      • Extra features
      • Task switching
      • Waiting
      • Defects
      • Management activities
  2. Build Quality In
    • Conceptual integrity
      • System’s separate components work well together as a whole with balance between flexibility, maintainability, efficiency, and responsiveness.
      • Embrace continuous refactoring
    • Continuous Delivery and Continuous Integration, TDD, release process, etc
  3. Create Knowledge
    • "Does your practice encourage systematic learning that enables the team to stay on track and make good decisions? And does it include mechanisms for the team to rapidly respond to this new knowledge?"
    • "A number of Agile practices are intended to provide the team with frequent and regular feedback that they can learn from"
      • Demoing the product to the customer at the end of each sprint to get the customer’s feedback
      • Regular retrospectives to understand how efficiently the team works together
      • Eg. "automated tests that get run with TDD and continuous integration practices to provides rapid feedback on the integrity of the software"
  4. Defer Commitment
    • Software is a knowledge-creating process, the more we build, the more we know. The best time to make decisions is Just In Time.
  5. Deliver Fast
    • “There are two ways to achieve high quality. You can slow down and be careful, or you can develop people who continually improve their processes, build quality into their product, and develop the capability to repeatedly and reliably respond to their customers many times faster than their competitors.”
  6. Respect People
    • "Teams that are able to design their own processes and address complete problems"
    • "Give people the training, resources, and support they need to be effective"
    • "Foster pride in workmanship" --> engaged, thinking, proud and continually improving
    • Old managerial thinking: "The managers tell the workers how to do their own job."
    • Agile: "The managers are taught how to listen to the developers, so they can explain better what actions might be taken, as well as provide suggestions for improvements.""
  7. Optimize the Whole
    • Avoid "not my problem"
    • Think what's best for the team

The Process

  • Top to bottom:
    • Requirements
    • Roadmaps
    • Endeavours / Initiatives
    • Epics
    • Use Stories
    • Tasks

Roadmaps and Requirements

Roadmaps to Endeavours/Initiatives > Epics > User Stories process

Backlogs

  • "Prioritized list of work for the development team that is derived from the roadmap and its requirements"
  • "The most important items are shown at the top of the product backlog"
  • "The development team doesn't work through the backlog at the product owner's pace and the product owner isn't pushing work to the development team."
    • The development team pulls work from the product backlog as there is capacity for it, either continually (kanban) or by iteration (scrum).
  • Product Owner prioritizes the backlog
    • What may influence a product owner's prioritization?
      • Customer priority
      • Urgency of getting feedback
      • Relative implementation difficulty
      • Symbiotic relationships between work items (e.g. B is easier if we do A first) <-- dependencies
    • "it's not done in a vacuum. Effective product owners seek input and feedback from customers, designers, and the development team to optimize everyone's workload and the product delivery."
    • "Product owners should review the backlog before each iteration planning meeting to ensure prioritization is correct and feedback from the last iteration has been incorporated."
      • In large and complex (lots of deps) projects, this turns out to be a lot of work for the Product Owner
      • Can be offset by delegating product backlog responsibility for individual projects
    • "Product owners dictate the priority of work items in the backlog, while the development team dictates the velocity through the backlog. This can be a tenuous relationship for new product owners who want to "push" work to the team."
  • The product backlog also serves as
    • the foundation for iteration planning
    • connection between the product owner and the development team
    • medium for discussion around what's important to foster a culture of group prioritization ensuring everyone shares the same mindset on the program
  • Further reading

Sprints vs. No Sprints

  • Scrum vs. Kanban vs. Lean

Tracking the work

Proposal for PL

  • Lean-ish
  • No fixed sprints, but Kanban approach
  • Generate: (Requirements) --> Roadmaps --> Backlog --> Goals / Stories
  • Start a backlog, keep it up to date
    • Each project has their own backlog
    • Master Backlog --> overview of all projects, all endeavours in one
  • Assign "Product Owner" or "Leads" for each sub-project
    • They can work on their respective backlogs without Juan's hand-on invelvement
  • Use GH milestones for releases, each goal/user story/feature/bugfix that gets done gets to a release
    • These can be on a fixed schedule
  • Simple workflow steps:
    • Backlog
    • TODO
    • WIP
    • Done
    • (Blocked)
  • Flow: pull instead of push
    • Indication mechanics with GH labels
  • Kanban boards for each project, one "master" board
  • Continuous Deployment
    • Don't need continious release, but make sure master is always deployable
  • Start paying attention to waste, automate everything you can automate
    • "This is a waste of my time"
    • Avoid writing anything twice
  • Weekly "sprint" update
  • Weekly planning / backlog updates overview
  • Keep working on the backlog as priorities change and new things pop up
  • Monthly review / retrospective
    • "What did we get done this month?"
    • "How did we do?" --> keep learning
  • Quartely review / retrospective
    • Much like now
    • Understand the users
    • Review user feedback
    • Discuss and generate roadmaps, split to "Epics" (eg. Pubsub)

TODO

  • Write a process definition document (this ^) to work as a baseline for further iteration
  • Train people on Product Requirement Documents and Backlogs
  • Design workflow steps, setup boards
  • Research other OS projects and see what we can learn and incorporate into our process
  • Iterate, iterate, iterate
  • Profit!

Further Reading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment