Making a successfull team is not that hard. Already in 1965 Tuckman described the different stages a team needs to go through to become a successfull team. Because these stages apply to small teams, up to twelve people, his lecture can be applied to scrumteams.
Source: https://en.wikipedia.org/wiki/Tuckman%27s_stages_of_group_development
Thursday, 14 July 2016
Wednesday, 13 July 2016
Deployment Pipeline
I just finished one of the best books about software development ever. It's called The Phoenix Project. The nice thing about this book that it is written like a novel and not like a bone dry study book. I want the share the following quote:
"Your next step should be obvious by now Grasshopper. In order for you to keep up with customer demand, which includes your upstream comrades in Development", he says, "you need to create [...] a deployment pipeline. That's the entire value stream from code check-in to production. That's not an art. That's production. You need to get everything in version control. Everything. Not just the code, but everything required to build the environment. Then you need to automate the entire environment creation process. You need a deployment pipeline where you can create test and production environments, and then deploy code into them, entirely on-demand. That's how you reduce your setup times and eliminate errors, so you can finally match whatever rate of change Development sets the tempo at."
Source: The Phoenix Project
"Your next step should be obvious by now Grasshopper. In order for you to keep up with customer demand, which includes your upstream comrades in Development", he says, "you need to create [...] a deployment pipeline. That's the entire value stream from code check-in to production. That's not an art. That's production. You need to get everything in version control. Everything. Not just the code, but everything required to build the environment. Then you need to automate the entire environment creation process. You need a deployment pipeline where you can create test and production environments, and then deploy code into them, entirely on-demand. That's how you reduce your setup times and eliminate errors, so you can finally match whatever rate of change Development sets the tempo at."
Source: The Phoenix Project
Tuesday, 21 June 2016
Product driven development
The majority of problems in becomming an agile organisation is classic thinking. When offices started and people moved into cities to sit behind a desk the whole day there was no real format of how people should work together in an office environment. So the closest example of teamworking was adopted; the military style. Strong hierarchical systems ruled by a despot many called boss.
People worked as teams on farms bringing in crops before the rain; all the thinking was product based and result driven. And within a couple of years the office crowd clotted the system with a new way of working. People started to think in responsabilities and processes.
With Prince and ITIL the process driven development had it's heyday's. After a hundred years of officework we finally beginning to understand that the way we worked together the thousands of years before the offices existed we worked very well as self-driven/organising/steering teams. And now we call it Agile.
The most companies I have worked for are strugling adopting agile software development. They are trying to implement agile as the next perfect solution, become scrummish, adopt some devops, define a developmentstreet and buy some tools like Jira. All in all they are still process driven and don't think in products.
The main difference between old school software development and new school is project- versus product thinking. If companies start to focus on products and added business value and use their common sense; there is nothing hard to become agile. It will come naturally. There are actually no rules to agile, there is no one way, no golden nugget, no perfect.
If we throw away processes, we can focus on products. If we throw away command-and-control we enable people to think again. Think of the end product, about quality and come to a consensus how to develop and maintain that product. And share the pain and the success of the product with all involved!
People worked as teams on farms bringing in crops before the rain; all the thinking was product based and result driven. And within a couple of years the office crowd clotted the system with a new way of working. People started to think in responsabilities and processes.
With Prince and ITIL the process driven development had it's heyday's. After a hundred years of officework we finally beginning to understand that the way we worked together the thousands of years before the offices existed we worked very well as self-driven/organising/steering teams. And now we call it Agile.
The most companies I have worked for are strugling adopting agile software development. They are trying to implement agile as the next perfect solution, become scrummish, adopt some devops, define a developmentstreet and buy some tools like Jira. All in all they are still process driven and don't think in products.
The main difference between old school software development and new school is project- versus product thinking. If companies start to focus on products and added business value and use their common sense; there is nothing hard to become agile. It will come naturally. There are actually no rules to agile, there is no one way, no golden nugget, no perfect.
If we throw away processes, we can focus on products. If we throw away command-and-control we enable people to think again. Think of the end product, about quality and come to a consensus how to develop and maintain that product. And share the pain and the success of the product with all involved!
Wednesday, 24 February 2016
Ready making
Working with an unmanaged Jira instance brings a lot of chaos. While on one hand people working with Jira should be given the freedom to make their own workflows in an Agile environment, on the other hand this freedom stands in the way of creating a Continuous Delivery factory. Grinding through many instances of Jira I find a lot of similair differences. The most common anomaly are different statusses in workflows that are actually transitions. I want to elaborate on one in particular: the "Ready" status.
In a lot of Scrum projects I see people who make issues "Ready". The term "Ready" sounds strange to me, because it looks to me as making something ready to be picked up by a Scrum team is just the transition from a "New" issue to an "Open" issue. Is this a too short approach? Let's find out.
The process of making issues ready for development contains the following tasks:
To complete the above steps the refinement discipline in Scrum is the solution. All items with status "New" cannot be picked up before the refinement is done; refinement is the step in which issues are made ready. Refinement is not done in a Scrum event, it is a continous process between the Scrum master, Product owner, stakeholders and the team.
All items in the "Open" status ought to be groomed enough to be picked up, teams can define a threshold of quality for "Open" tickets; this is written down in a Definition of Ready. A DoR can be different for different teams.
Resources:
In a lot of Scrum projects I see people who make issues "Ready". The term "Ready" sounds strange to me, because it looks to me as making something ready to be picked up by a Scrum team is just the transition from a "New" issue to an "Open" issue. Is this a too short approach? Let's find out.
The process of making issues ready for development contains the following tasks:
- Dependencies; Is there other work to be completed before this issue can be solved?
- Skills; Is the team skilled enough for this task?
- Space; Is there room in the code to make the change, or do we need too much refactoring?
- Design.; Does the user story have design and workflow?
- Stakeholders; Who is involved in the user story and has a say (is he the Reporter)?
- Work ahead; are there any issues dependent on this one?
- Following work: are the recievers of this work ready to recieve it?
- Requirements: Functional and non-functional requirements are clear?
- Acceptance: Acceptance criterea are clear?
- Flows: Are the happy and bad flows defined?
To complete the above steps the refinement discipline in Scrum is the solution. All items with status "New" cannot be picked up before the refinement is done; refinement is the step in which issues are made ready. Refinement is not done in a Scrum event, it is a continous process between the Scrum master, Product owner, stakeholders and the team.
All items in the "Open" status ought to be groomed enough to be picked up, teams can define a threshold of quality for "Open" tickets; this is written down in a Definition of Ready. A DoR can be different for different teams.
Resources:
- http://leanmagazine.net/lean/make-ready-agile-projects/
- http://guide.agilealliance.org/guide/definition-of-ready.html
- http://www.allaboutagile.com/is-it-ready/
--
02-03-2016 Updated grooming to refining
Saturday, 9 January 2016
Thursday, 7 January 2016
Test automation?
bash.org #950581
- < Ergo^> Six Stages of Debugging
- < Ergo^> 1. That can't happen.
- < Ergo^> 2. That doesn't happen on my machine.
- < Ergo^> 3. That shouldn't happen.
- < Ergo^> 4. Why does that happen?
- < Ergo^> 5. Oh, I see.
- < Ergo^> 6. How did that ever work?
- < MatthewWilkes> 7. svn blame
- < miniwark> 8. one day we will write tests
Subscribe to:
Posts (Atom)