The Art Of Possible

I am just infatuated with the ideas of continuous improvement and collective intelligence.  That lead me to study the Scrum method of software development.  It centers around self organized, self managed teams, and bite-size tasks.

The term “Scrum” comes from Rugby.


Here are my notes from Agile Project Management With Scrum. Now, I am not convinced scrum is the end all, but the self organization is lovely.  I am interested in taking the best practices from Scrum, Kanbam,  RUP, and many others to form a comprehensive, scalable solution.  See, scrum isn’t suited for very small projects, but the concepts are strong.  Here are my notes on the book.  Beware, some of the notes are my thoughts on the book.

  • Most process improvement systems are some for of Deming cycle.
  • Scrum is used in work that is impossible to predict.
  • Think of building a house:  the scrum/agile way you would build a complete room with pluming , electricity, etc.  they could move in quicker and decide how they want to proceed next. Rather than one category/layer at a time - framing, plumbing, electrical etc.
  • Defined process control - when everything is predictable
  • Empirical process control - when you have to figure it out as you go along
  • Empirical is much more expense at first, but is more precise.  It’s also cheaper than using dpc and reworking the product.
  • Visibility - process must be visible and truth based. No deception.
  • Inspection - for bad deviations from the process
  • Adaption - able to adapt when a process is producing low quality.  must be done quick;y.
  • Tasks are 4-16 hours .  anything over is considered not broken down yet.
  • Scrum master more like sheepdog.  they manage the processes. Process manager would be a good title.
  • The 30 day sprint balances the war between sales and development.  developers get to focus for 30 days, while the sales dep gets to add their input every 30 days.  a balance of focus and responsiveness.
  • The first sprints don’t output a lot of business functionality because of architectural needs.
  • Give the team authority to do anything they need to get the sprint done, within basic rules.
  • The true productivity from scrum comes from team self organization.  once they puzzle their way through the problems, they have buy in and high productivity.
  • Thoughts -  provide the goal, resources and education, let the team self organize.
  • Iteration planning is about the art of possible, rather than the pursuit of perfection.  Time box the meeting.  It’s not about figuring it all out.  Those conversations will never end.
  • Seems like that could be applied to everything.
  • Epc and how it morphs.
    as the degree of complexity rises, the amount of inspection increases. Because inspection increases, so does adaption
  • Inter disciplinary teams are a must when there is a lot of complexity.  team members that have authority in other parts of the application meet the requirement.  that way when one module is stuck waiting for some other, the member can go to the problem module and improve it.
  • Maybe the term should be cross authority teams. And teams should be built with members which have unique emphasis - usability, security, fault tolerance, etc.
  • Scrummaster teaches everyone to speak the same language.
  • People that use defined control process, and fail, blame themselves for not being strict enough.  Creating software is just not definable exactly. Unlike producing cars, software that is written is only written because it hasn’t existed yet.  Duplication is the most the work of car making.  Software, all the work is in a unique design.
  • Scrum managers measure and track requirements, not tasks.
  • Scrum expects changes, and it’s reports reflect how those changes have effected the project.
  • A scrum meeting shouldn’t follow a personality, it should follow rules.
  • The scrum master is there to ensure rules are upheld, and any impedances are removed.
  • Self managed is hard to grasp.  they really are just let go to figure it out.
  • Everyday, the code must be checked in, and tested.  Inspect and adapt is the scrum mantra.
  • Scrum doesn’t seem to address nesting of requirements: sub requirements.
  • Inspect and adapt is what to do during retrospectives. Teams probably will have to self organize anew every couple of sprints.  don’t worry about permanent solutions.
  • Perfection in planning will never happen.  if the teams need to reorganize during the sprint, it’s up to them.
  • The first sprint is always under estimated.  they aren’t used to a true definition of ‘done’.
  • Sub optimal measurements: measuring the output of programming from the wrong perspective.  forcing them to stay within 20% of their estimate, they will sacrifice quality, and will meet the deadline.
  • As the manager - scrummaster or product owner, you mange what you want out of the team.  they manage the ‘how’.- product owner - what
    - scrum master - what process/guides/laws
    - team - How
  • Also, make sure the programmers are in the same location, if possible.  They will need face time.

Next entry

Previous entry

Similar entries