Category: Management


Scrum in one page

Filed Under: Management by Robert Corvus — Leave a comment
October 18, 2011

Here is the Scrum agile method summarized in one page:

How the Scrum method works:

  • There is one Product Owner (e.g. a business analyst) for each project and he/she creates a prioritized wish list called a Product Backlog.

    • The backlog is an ordered list where the most urgent item is #1, the second most urgent item is #2, etc.

    • The Product Owner is the only person who can change the priority of items in the Product Backlog.

  • During Sprint Planning, the team (i.e. developers, testers, and dbas) pulls a small chunk from the top of that wish list (i.e. the most urgent items) and decides how to implement those pieces.

    • This chunk of the Product Backlog is called the Sprint Backlog.

  • The team has a fixed amount of time, a Sprint, to complete its work (usually two to four weeks) and meets each day to assess its progress (daily scrum).

  • During the sprint, the Scrum Master keeps the team focused on its goal and removes impediments to productivity.

  • During the sprint, the Product Owner can change priorities in the Product Backlog, but cannot change priorities to the Sprint Backlog.

    • The Product Owner is the go-to person for the team to get clarification on functionality or usability.

  • At the end of each sprint, the work should be code-complete, tested, and ready to deploy to prod.

    • Items not completed are put back into the Product Backlog, to be finished in a later sprint.

    • Therefore the sprint deadline is never extended to finish items or for any other reason.

  • The sprint ends with a Sprint Review and Retrospective

    • Sprint Review is where the sprint’s progress is demoed and discussed with the product owner (and ideally, the customer).

    • Sprint Retrospective is where the team discusses ways to improve productivity and eliminate pain.

      • Rule #1 of the retrospective is that no person or part of the organization is allowed to be blamed for problems. Processes allow people or parts of the organization to be inefficient, therefore the discussion focuses on how processes can be changed to improve the situation or remove impediments.

      • The best improvements are taken from the retrospective and implemented in the next sprint.

  • As the next sprint begins, the team chooses another chunk of the product backlog and begins working again.

  • The cycle repeats until enough items in the product backlog have been completed for a prod release or a deadline arrives. However, work can be stopped at anytime and finished items can be deployed to prod in a short amount of time in a fully workable and tested state.

(This is a summary of the Scrum Framework in 30 Seconds – yes, a summary of a summary)

Tags: , , , , ,
Comment

Written vs Spoken Rules

Filed Under: Management by Robert Corvus — Comments Off
August 19, 2011

If you know the story of Moses, he was an old-school manager of legendary ability who laid down the law for his people.  To get a clue as to one of his techniques, you have to ask yourself, how did he convey the prime directives to his people?  Were they mentioned in a status meeting, jotted down on papyrus, or sent out as an email?  No, they were written in STONE.  Something tangible, long-lasting, and symbolic of strength and immortality.  The next time you feel that your teammates are not getting your message, rock it old school and write it down for them.

Tags: ,
Permalink

Point It Down Range

Filed Under: Management by Robert Corvus — Comments Off
August 4, 2011

A rifle instructor knows how dangerous a rifle is and makes sure every one of his riflemen keep their guns pointing down range rather than at each other. Any great team will have an enormous supply of competitive energy, and much like a rifle, this competitive energy can be dangerous to the team if it’s pointed inward.

A key role of a leader is to harness all that hyper-competitive energy and point it down range. A leader needs to make sure competition doesn’t turn inward and become self-destructive, devolving into political infighting. A leader gives his team someone or something outside of the team to focus on and target with their attack energies. A great leader rallies his troops against either a common enemy outside of the organization such as the company’s competitors or on an opportunity for fame and fortune. Team meetings are not about how the team sucks but about how the team can build it’s strength to beat a common enemy and attain glorious victory.

Tags: , , ,
Permalink

Clarity is needed for the success of a software project

Filed Under: Management by Robert Corvus — Comments Off
February 22, 2011

Have you ever heard crickets chirping when you announced your product? Sucks, doesn’t it? A lack of enthusiasm from customers or even your own sales team is a sure sign that your product fails to meet demand. While it’s true that a project is a success if it meets the needs and expectations of consumers within the constraints of the project, it is more accurate to say that a project is only considered a success if it’s perceived as a success. In order to have your project perceived as a success, you need to manage expectations. And the way to manage expectations is with clarity. A successful project needs everyone involved with the project to have a clear purpose, clear priorities, clear use-cases, clear estimates, and a clear understanding of dependencies and uncertainty. Fully expanding these points could easily fill entire articles (or books), but here’s a basic recipe for making a software project successful.

View full article »

Tags: , , ,
Read More

Kanban vs Scrum

Filed Under: Management by Robert Corvus — 1 Comment
December 2, 2010

Jeff Cohen has a nice comparison of Kanban vs Scrum. In a nutshell, Kanban emphasizes pull- instead of push-based queues which, among other benefits, is better at handling non-brick-laying development (i.e. new tools, new languages, new problems) where time estimates are hard to judge. From Jeff Cohen:

Kanban
Goal/Theme: Maximize flow through your development department by introducing the concept of limits.
NOTES:
Can work alongside scrum in terms of requirements mangement; but replaces the predictive, timeboxed, pushed-work sprint system with a series of small work queues from which all team members “pull” tasks whenever they’re ready for new work. Velocity is still a measurement of how many features/bugs/tickets that can flow from the starting queue to the final queue in a given week or month.
Kanban does not prescribe any meetings; the ability of the team to figure out their own communication style is assumed. Many teams adopt the estimation and prioritization concepts from scrum to manage the requirements and decide what goes into the kanban queues. Search google for “scrumban” to get a variety of opinions on this.
+ drives progress within a team or across multiple teams equally well
+ the notion of limited work queues tend to improve focus and remove excessive context-switching
+ no sprint predictions: team members pull new work whenever they’re ready for more
+ deployment/release management not a special step, but simply another kanban queue
+ features can be released can occur in step with, or out-of-band of, ongoing development
+ engineers can work on short tasks, or long-running tasks, without the limited timebox of a scrum sprint
- no prescription for how to manage requirements
- no opinion on management technique; many kanban teams choose a simplified version of scrum
- some people think it’s “scrum without sprints,” but that underestimates the subtle but important difference between pull* – vs. push-based work scheduling

The article also compares the other methodologies such as Waterfall, XP, and everyone’s favorite: Chaos.
http://www.softiesonrails.com/2010/2/1/waterfall-scrum-and-kanban-oh-my

Tags: ,
Permalink
© 2012 Robert Corvus