Books:
Leading Lean Software
Reinventing Organizations - Frederick L.
- Agile Pizza - A painful game to play where you will probably get in a fight with your team and learn a lot about yourselves and how you work under pressure.
- Coin game (flip coins and pass to next player) - Shows that removing impediments (processes, positions, management) can only assist in higher delivery rates when the measure of success is working software. (The deployment process is an unnecessary time loss for developers. This should be done by devops or sys admins where possible.)
- Numbers game - Shows the cost of context switching
- Card game - shows the cost of interruptions and poor workstreams. Shows the benefit of swarming in the end by rallying around single issues as a team.
- Ball and sticks - represents the movement of a team and their codebase and how a team must collaborate to protect eachother.
- Binning with cats - Creates a baseline for estimation.
- Regarding working dynamics, the Scrum Master is responsible for the health and wellness of a team. A team therapist who assists members in seeing the bigger picture and why teammates are making the decisions they are making. This also creates a need for the SM to know and understand personality types and how they relate to the dynamics at play in an environment and how to make the best use of them.
- The SM plays a large role in keeping the culture acidic or fertile.
- SM redirects blame with reality ("he had these other things on his shoulders, so he had to sacrifice X, Y, and Z as a result")
- A servant-leader - invested in the team, not the product.
- Ensure everyone has a shared understanding.
- Agile allows for cost and time to be fixed (the most important items to management) while allowing the scope of a project to be negotiable with the customer.
- It is an iterative approach toward a larger goal that forces the customer to consider what their higher priority items are for the sake of sooner delivery.
- Expectations can be managed dynamically and more often. Agile forces a shared understanding.
- Pragmatic Programmer: "Make the smallest change that is easiest to change in the future" This encourages thought between balancing the size of the current change with the size of a possible change in the future.
- Don't solve problems you don't already have.
- Look above the weeds often (your SM should also be doing this for you) to ensure that you see how your efforts fit into the big picture.
- 80/20 rule - tackle the one that 80 will see first. It is higher priority by nature.
- Really listen to the customer and their needs.
- Bring the customer in early and often.
- Ensure regular checkpoints
- Customer buy-in and ownership of processes is a tremendous assist where possible.
- A plan is nothing more than a guess
- Agile should have no change management process
- Vertical slice delivery ensures that a system is being iterated on in such a way that measurable value (working software) is being delivered.
- Task boards visualize and highlight bottlenecks in development.
-
Course Definition - A small number of people with complementary skills who are committed to a common purpose, set of performance goals, and approach for which they hold themselves mutually accountable.
-
Class Definition: An organized group of people with defined roles
-
Desires for a team:
-
Comfort
-
Safety
-
Empowerment
-
Clarity
-
Trust
-
Collaboration
-
Group thinking
-
Fun
-
Sense of duty/purpose
-
Want to be around each other
-
Named roles create boundaries that people don't want to cross.
- A component team will all have relatively similar skill sets (all front-end engineers for example)
- A feature team will have complimentary skill sets with perhaps some overlap of knowledge between some members.
- Feature teams provide better integration between components due to the collaboration that takes place.
- Responsible for creating and refining the backlog.
- Serves as the voice of the stakeholders and is internal facing to the development team.
- Protects the team from noise and pressure.
- Makes connections/networks as needed.
- Empowers the team and protects from noise.
- Gives the team space to have and solve problems on their own.
- Evaluates dev team's implicit and explicit assumptions (and ensures accuracy where required)
- Is a facilitator, not a tech lead.
- A data tracker/analyzer who proves or disproves the viability of processes.
- Has power to negotiate the product backlog & priority
- Should be cross-functional for optimized delivery.
- Nurtures teams and individuals
- Aligns the environment towards the Agile mindset
- Communicates the vision and goals of the organization.
- Possibly leads functional communities of practice (Testing, UI, BI)
Page 38. While we don't have a high turnover, I'd be interested in knowing where the I.T. team feels we are on this pyramid.
- Creates a need for focusing on understanding personalities.
- What needs someone has
- How someone needs to be interacted with.
- Self actualization shifts personality (Why is this here?)
- Agile principle 6: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Distributed teams must overcome the lack of feeling like a team.
- "We believe in , so we will ."
- Values, Principles, and Practices (I don't know these for our team, but I also am not certain it is needed for us).
- A must for teams
- What areas might we not have shared understanding?
- Assists the customer and tech team know and understand who the user is. This ensures a shared understanding.
- Helps stakeholders give input based on what the user wants instead of what the stakeholder wants.
- The point of prioritization is to focus on what is most valuable to your customers and stakeholders.
- Understanding value uncovers motivations, risks, and acceptance criteria.
- (Shared understanding) creating a baseline for estimation allows teams to estimate more effectively.
- (Page 66) Why don't we do the portfolio or product planning? (6 months and beyond)
- I would imagine this kind of planning could be useful for something like the donation system.
- All about priorities and feature sizing.
- Why don't we do this for any of our products?
- This is not a status meeting, it is a planning meeting.
(Page 72)
- Do we all find value in the daily standup?
- Planning communicates intention.
- Planning is about the conversations and shared understanding, not about the plan.
- Delivering in vertical slices allows the customer to benefit from complete and usable features.
- Simple Design
- Test Driven Development
- Continuous Integration
- Continuous Delivery
- Automated Testing
- Refactoring / Reengineering
- Strong Definition of Done
- Limit work in progress
There are time and monetary costs associated with context switches. (Numbers game)
I believe this is more of an issue from a long-term planning perspective for us.
- Represents money spent with no return (or value) delivered.
- Hides bottlenecks and masks efficiency issues
- Adds risk of rework.
- Only one workstream per team.
- Teams should be brutally honest and transparent about not meeting goals as early as possible.
- If nothing is broken by it, each accepted item should be deployed to production immediately following.
- Exclusively owned by the SM.
- Time for analyzing and refining team dynamics.
- Several techniques exist for conducting this meeting.
- Don't forget the team's conflict norms and working agreements during the retro.