February 10, 2012
0 Comments
Forget the charts. Forget the rules. Talk, trust, learn, adapt. The tools are just that, tools. Use the ones that work for you. On this project. With this team. Success does not hinge on whether you use Jira, or Mingle, or Pivotal Tracker, Google Docs, or Excel, or sticky notes, or hand signals and a series of grunts.
(Full Story: Agile Reboot: Putting the Man back in Manifesto)
January 12, 2012
0 Comments
To complete projects of 100,000 equivalent source lines of code (a measure of the size of the project) they found the large teams took 8.92 months, and the small teams took 9.12 months. In other words, the large teams just barely (by a week or so) beat the small teams in finishing the project!
Given that the large teams averaged 32 people and the small teams averaged 4 people, the cost of completing the project a week sooner with the large team is extraordinary: the large teams would have spent $1.8M while the small teams only spent $245k
(Full Story: Small teams beat large teams in software development | Atomic Spin)
December 12, 2011
0 Comments
Small units of work
Optimize for value
Iteration
Product owner involvement
Feedback
Honesty and trust
(Full Story: Why We Are an Agile Shop | The Carbon Emitter)
December 7, 2011
0 Comments
(Full Story: sprint.ly – Make beautiful products.)
November 2, 2011
1 Comment
“The ideal work planning process should always provide the development team with best thing to work on next, no more and no less.”
(Full Story: Scrum-ban | Lean Software Engineering)
October 26, 2011
1 Comment
For me, going from a non-agile development methodology to an agile one should have been simple. I had read the articles, attended the seminars, and knew the theory. However, what I did not have was a basic template for project tracking throughout an iteration. This article provides that template with the burn down chart shown below being the end goal. The only tool we need is a spreadsheet.*
(Full Story: Burn Down Chart Tutorial: Simple Agile Project Tracking in Excel)
October 4, 2011
0 Comments
Towards agile architecture
Architecture throughout the lifecycle
Who is responsible for architecture?
Have an “architecture owner” role
Agile architecture at scale
Base your architecture on requirements
Model your architecture
Consider several alternatives
Remember enterprise constraints
Travel light
Prove your architecture with working code
Communicate your architecture
Think about the future, just wait to act (defer commitment)
Take a multi-view approach
How does this work?
Who is actually doing this?
Addressing the myths around agile and architecture
(Full Story: Strategies for Scaling Agile Development)
August 31, 2011
0 Comments
Because, when the discussions don’t occur, the technical group takes all the responsibility for the product: for what to build, when to build it, and for how to build it. And that means we have let the rest of the business abdicate all of their responsibility for their part of the product. That’s not the partnership agile promises us, nor is the transparency agile promises us.
(Full Story: When You Have No Product Owner At All)
August 23, 2011
0 Comments
(Full Story: Strategies for Scaling Agile Development)
August 14, 2011
0 Comments
Vision + Team as inputsProduct + Team Capability as outputsAn Initial Product Backlog that feeds into the Sprint CycleWithin the Sprint Cycle we have all the tasks that make up a sprint – planning, sprint backlog, product increment, sprint review, sprint retrospective, updated product backlog
(Full Story: A new and improved Scrum Diagram)
