Although my personal score (86%) did include some stupid errors it seems that, from the overall results, it is quite good. Well above the required 75% anyway to be Scrum Level I (since Wed 14th Oct 2009).
Is there a way to check on the correct application of Scrum?
Most attempts end up in complex questionnaires or big assessments. This is strange as Scrum is a simple process and has distinct definitions of roles, artefacts and meetings. And I also distinguish core principles.
When presenting Scrum as the core process of my My.Fragility framework I always show my Scrum Diamond, a graphical representation of the 3 essential elements for each of the 4 Scrum ceremonies:
It makes an assessment of Scrum simple: check whether the process and the above ceremonies are in place!
And remember: Scrum prescribes a minimal, but tightly coupled, set of ceremonies. Skipping even only one implies affecting the essence of Scrum. Doing so does not necessarily mean that you are not Agile or don’t perform well, but don’t call it… Scrum.
- It started in 2003 with eXtreme Programming
- In 2004 I started using Scrum and certified as a ScrumMaster
- I’ve always applied personal practices for fixed timeframe projects
- To prepare projects I use a Product Backlog Estimation model
- I track development with my Product Backlog Tracking model
I have started distributing my documentation on it, beginning with my overall presentation: My.Fragility – The Essential Scrum and beyond (handouts) (4 MB).
- an introduction on the general position, maturity and adoption of Agile as a software development method
- a focus on the process of Scrum
- the specific elements (and additions) of My.Fragility
- addenda on eXtreme Programming, references and the roots of Agile
Find all my notes on my framework under the tag my.fragility.
Or stay really tuned via RSS http://en.wordpress.com/tag/my-fragility/feed/
The book Implementing Lean Software Development (from concept to cash) by Mary and Tom Poppendieck gave me an additional perspective and language (terminology) on quality and testing, thus enriching my existing insights.
Traditional testing is focused too much on bug hunting, mostly after a development cycle and including a devious rewarding or penalty policy. There is too little attention for verification of quality while building.
The development process should be oriented towards creating quality upfront (i.e. before UAT, release or whatever post-process control), and verification during the development process. If verification reveals a defect, the ‘line’ is stopped, the cause identified and resolved.
My My.Fragility framework holds Quality Loops. These are performed continuously and at least daily. It is based upon eXtreme Programming practices. They serve as engineering standards within the Scrum process that is at the heart of my framework. It shows our focus on quality and integrated testing:
Despite maybe chaordic circumstances, most (all?) customers are very attached to having a good upfront price indication. Even as a convinced Agilist and Scrum Practitioner I still want to serve those customers.
My My.Fragility framework tries to align both views upon a well-defined (Agile) Project Life Cycle:
During a (timeboxed) Pre-game staging effort, an initial Product Backlog is created, estimated and given a total price/elapse time (following my Definition of Agile Planning). The Product Backlog and Release Plan (split up of elapse time into monthly Sprints) is included in all proposals and contracts. It is the formalization of a mutual understanding and trust of what is included and what is not.
During implementation, the full Scrum process is applied, but the number of Story Points is kept in balance with the estimated number. I.e. when changing or adding User Stories, the priority of a comparably sized effort (in Story Points) should be adapted. And, yes, this might result in not implementing the lower priority Stories. Unless impact on timing and budget is accepted.
Keep track of the changes (delta) in a Delta Backlog.
Play the Planning Game with the customer to maintain the balance:
- During a Sprint, refine next priority Stories and assess their estimates upon the actual knowledge
- Let the customer decide on the selection of Stories for the next Sprint. Intervene as little as possible. Assist
- Iterate until the selected #Story Points matches the available #Story Points
So, Agile techniques may well be used to deliver total results in a fixed timeframe, when adding the notion of Negotiable Scope.
I included a Product Backlog Estimation model to calculate a total price using my Definition Of Agile Planning. And on top of User Stories and Story Points the Sizing of User Stories is to be considered:
The right size of a User Story is 0,5-5 ideal days (di) (ideal time = Story Points). For development. To be invEST. To comfortably fit a Sprint.
- Epic Stories can be 5-15 di. A size not suited for development but acceptable for estimating. To be split into User Stories.
- Cosmic Stories are >15 di. They can serve only as a beginning to understand a Product, not for estimation or development.
- Tiny Stories are < 0,5 di. To be combined into User Stories.
Note: ‘Minimal Marketable Features’ (MMF) from Kanban can be a set of User Stories. Possibly an Epic Story.
The best base to estimate is experience. When experience is limited, use relative estimates (complexity scaling). I use a 1-2-5 scale:
- Size is set upon complexity to 1-2-5-10-20-50-100-… Always use the higher value if you end up in between two points.
- Find some reference points in your experience to compare.
- Refine until you end up with real estimates (Story Points).
note: Ideal time is development time without breaks, questions, problems or any interrupts. It is multiplied with Velocity to get Planning days.
I have combined personal insights for fixed price (-negotiable scope) projects with practices from eXtreme Programming and Scrum in my My.Fragility framework.
The main estimation steps from the framework’s Product Backlog Estimation model were highlighted in my Definition Of Agile Planning. But the model also implies at least an understanding of some definitions.
After my definition for User Stories here’s how I use Story Points:
- Story Points equal ideal time (“ti”). But using ‘Story Points’ might prevent people from confusing it with realistic time. The eXtreme Programming notion of Gummy Bears (“Bg”) might be a bit too abstract, although it’s fun to use.
- Ideal time is the development time for a User Story without breaks, questions, problems or interrupts of whatever nature. Spending every minute of every working day on productive coding.
- Ideal time is mulitplied with Velocity (“v”) to estimate Planning time (“tp”). In my experience, an overall velocity of 2,5-3 results in a realistic number of planning days.
planning time (“tp”) = ideal time (“ti”) * Velocity (“v”)
- An alternative definition of Story Points is the number of productive coding hours per day. This is generally accepted as maximum 5-6. Velocity is then expected to be around 1,33.
Note I generally apply an overall Velocity to all User Stories, although my model allows a specific Velocity per User Story, e.g. depending on the expected complexity.
Over various projects I have applied a set of Agile practices from eXtreme Programming and Scrum. Adding personal insights to specifically handle fixed price (-negotiable scope) projects resulted in my My.Fragility framework.
The framework includes a Product Backlog Estimation model, for which the main estimation process steps were highlighted as part of my Definition Of Agile Planning. Furthermore does the model at least imply an understanding of my definition of a User Story:
A User Story describes a feature from an end-user perspective. It is independent of software layers or parts of the project
A User Story can be explained as an essential Use Case
A User Story should be INVEST to be ready for development
- Independent: User Stories have as little interdependence as possible. Resolve it by putting related Stories in the same Sprint
- Negotiable: a User Story is an invitation to discuss implementation. The best design and code result from communication!
- Valuable: a User Story represents effective business value for an end-user
- Estimatable: the size and knowledge on a User Story is sufficient to reliably estimate the Story
- Small: a User Story is small enough to be estimated, developed and tested. It is comfortably realizable in one Sprint
- Testable: a User Story has a clear result that can be tested
When reviewing Chet Hendrickson’s paper on the evolution of Extreme Programming practices, I was surprised that he completely ignored Kent Beck’s revision of 2004. As does Ron Jeffries’ practices representation, by the way.
5 Years of eXPerience resulted in a complete revision of Extreme Programming Explained. The general tone softened, partial adoption became acceptable and the practices were extended, and divided into primary and secondary practices. Maybe Kent considered XP as under-adopted, but I missed the strong and ahead leadership from v1. No compromise. Working software is the goal. Extreme focus. Programming is the way.
I also felt that in the v2 edition, good ideas were introduced, but good practices were also replaced. Because I instantiate Scrum’s engineering standards with XP practices in my framework My.Fragility, I decided to merge the best of both:
Note: when checking the original Extreme Programming Installed book myself, I wondered (after all these -6- years!) why it did not mention the Coach role. When moving to Scrum after our ‘pure’ XP application, I kept promoting this role. I still do in my My.Fragility framework (on top of Scrum’s Product Owner, Team and ScrumMaster).
And I still don’t known why User Stories was not an explicit XP practice from the beginning…
To review Chet Hendrickson’s retrospective paper on his book Extreme Programming Installed, I went back in time myself. Back to my first experience with Extreme Programming.
In September 2003 I was asked to urgently take on a project as project manager. Customer approval was late but the predicted delivery date remained (December).
A 15 min introduction convinced me of eXtreme Programming. Because so much was incorporated that was traditionally so easily forgotten or overlooked. We convinced management, and off we went (October). After 3 iterations (of 3 weeks) we delivered… in time and on budget!
Because I considered myself too illiterate (after all, we only did it) to present the project at Javapolis 2003, I started reading some books. The inevitable Extreme Programming Explained (‘Embrace Change‘), Planning Extreme Programming and… Extreme Programming Installed. It was remarkable to find that our ‘naive application’ was an extraordinary match with what I was reading. Presentation went very well.
In 2004 I started using Scrum as process and certified as a ScrumMaster. During follow-up projects for our satisfied customer we kept combining Scrum and XP. However, we had to operate within a context of realizing a (negotiable) scope in a given timeframe. So along the way (2004-2006) additional practices, tools and views were embedded, to finally become my My.Fragility* framework.
The framework holds following (partially XP based) Quality Loops:
Implementation of Engineering Standards. To be performed every day:
- A pair writes all code upon a Test First basis (including Selenium GUI tests)
- Checked in code is tested in a Continuous Integration system (multiple times a day) and can be refactored
- A ‘guide’ (additional, explicit role) functionally tests a stable, CI’ed version (multiple times a day) and feeds back results to the team
- A functional working version may be deployed for performance testing (running overnight)
* The name of the framework has its roots in the big relief I felt when morphing from project manager to ScrumMaster. The option to be fragile (agility through fragility), of not constantly having to intimidate people. Because, after all, it’s just a matter of talents and roles, not of… hierarchical slavery.