Saturday, December 27, 2014
Refactoring, functional and market requirements changes from the material product development world
https://medium.com/dome-kit/slow-flexible-cheap-5598ca91fb38
Monday, October 27, 2014
Exercises in Agile Discipline
In my previous post I wrote about how one of the primary things lacking in teams floundering with their attempts at Agility is a lack of discipline. I also linked to articles on two particular disciplines: Timeboxing and Feedback loops.
In reality, every process part of Agile Delivery can be thought of as applying a timebox, setting up and using feedback loops, or a combination of both. The timebox and the feedback loops are the mechanics by which we traverse problem domains in an Agile manner. Problem domains can be delivery of a product (software or other), organizational transformation, team or self improvement, holding a party, or any other problem complex enough to be broken into steps, but also vague enough that the understanding of the constraints around successfully solving it will change over time until the time of the completion of the solution.
Every timebox should be defined as the shortest amount of time in which to produce a meaningful result. By meaningful result we want to focus on:
In another prior post I compared using these disciplines to the use of footwork in a martial art. In the fencing salle, footwork is so important, so foundational, that we have had new students spend at least a month doing nothing but footwork before they were even allowed to touch a weapon.
In reality, every process part of Agile Delivery can be thought of as applying a timebox, setting up and using feedback loops, or a combination of both. The timebox and the feedback loops are the mechanics by which we traverse problem domains in an Agile manner. Problem domains can be delivery of a product (software or other), organizational transformation, team or self improvement, holding a party, or any other problem complex enough to be broken into steps, but also vague enough that the understanding of the constraints around successfully solving it will change over time until the time of the completion of the solution.
Every timebox should be defined as the shortest amount of time in which to produce a meaningful result. By meaningful result we want to focus on:
- Delivering requested value,
- Coming to a better understanding of what value to deliver next,
- Coming to a better understanding of what value remains to be delivered, or
- Coming to an understanding on how to better do the first three.
Feedback loops are essentially a series of timeboxes in which one of points 1-3, as well as some information about point 4 is gleaned from each timebox and fed into the next in the series.
In another prior post I compared using these disciplines to the use of footwork in a martial art. In the fencing salle, footwork is so important, so foundational, that we have had new students spend at least a month doing nothing but footwork before they were even allowed to touch a weapon.
If timeboxing and feedback loops are such foundational disciplines in Agility, we should all be rigorously exercising in using them. To that end, I propose the following challenge exercises. These are simply suggestions of where to apply the disciplines, not a complete exercise regimen. You can choose to do one, some or all of them and in whatever order you deem appropriate. Better yet, come up with your own regimen from these or other exercises and post it here for others to try!
- Pick some chore or home project you are having difficulty finishing and set aside a timeboxed amount to work on it each day for a week (notice, the week is itself a timebox). Assess your progress after each session and at the end of the week.
- Pick some chore or project your kids are having trouble finishing. Have them determine the timebox for each incremental progress. You facilitate the assessment at the end of each increment and the end of the week.
- Try using the pomodoro technique at work or at home.
- Take one of your agile ceremonies or meetings on your team and try to make it more effective using timeboxing.
- Apply timeboxing to breaking down large stories.
- (This can be done individually or even better, as a team exercise) Make a list of all the time-boxes your team is employing - whether consciously or not. Now, from this list, make a list of all the time-boxes where feedback could be collected but is not. Pick the most impactful missing feedback timebox. Start tracking the feedback from this timebox and discussing it before the next subsequent, related timebox. See if performance improves from loop to loop over time.
Tuesday, October 21, 2014
3 Ways to Get Control of Your Agile Teams
Your company rolled out its Agile initiative 6+ months ago. A team or teams under your leadership received the green light to manage itself in the approved flavor of Agile (usually Scrum). Team members have attended training. The team meets every day or at least once an iteration. There has been a Scrum Master appointed to the group. Yet the project(s) worked on seem to be slipping as each week goes by. You are assured that stories are being completed, yet you have no idea whether you are going to meet the deadline, let alone what is being developed toward that goal. Your situation feels less Agile and more like Anarchy.
Dire as this example seems, it is not far off the mark for many teams and companies who have given this 'Agile thing' a go. Here are three tips used by successful Agile teams you can use to regain control of your team, its delivery of value and avoid the brink of chaos.
1) Agile Metrics.
Despite the impression of some that Agile is just a free wheeling approach to development, the best Agile teams know that the built in feedback loops provide the perfect means to collecting tons of accurate data. Even if your teams have not implemented the tightest loops, like those around automated testing and pairing, they should be able to give you a fairly current Velocity measurement of the team's progress toward completion of the project as it is currently defined. This measurement is much more than a simple ratio of work not done to work remaining, but rather provides insight into numerous impacts on a team, including partial allocations, tech debt, changes in requirements, or lack of experience. Get your scrum master/project manager/team lead to track the team's velocity iteration after iteration. Trouble spots will become readily apparent and it will give you and the team something concrete to figure out how to improve. The team should start measuring its progress and those metrics should be openly communicated.
Here are some other metrics that you can glean from the Agile feedback loops available to you:
Dire as this example seems, it is not far off the mark for many teams and companies who have given this 'Agile thing' a go. Here are three tips used by successful Agile teams you can use to regain control of your team, its delivery of value and avoid the brink of chaos.
1) Agile Metrics.
Despite the impression of some that Agile is just a free wheeling approach to development, the best Agile teams know that the built in feedback loops provide the perfect means to collecting tons of accurate data. Even if your teams have not implemented the tightest loops, like those around automated testing and pairing, they should be able to give you a fairly current Velocity measurement of the team's progress toward completion of the project as it is currently defined. This measurement is much more than a simple ratio of work not done to work remaining, but rather provides insight into numerous impacts on a team, including partial allocations, tech debt, changes in requirements, or lack of experience. Get your scrum master/project manager/team lead to track the team's velocity iteration after iteration. Trouble spots will become readily apparent and it will give you and the team something concrete to figure out how to improve. The team should start measuring its progress and those metrics should be openly communicated.
Here are some other metrics that you can glean from the Agile feedback loops available to you:
- http://agileatlas.org/articles/item/metrics-for-a-scrum-team
- http://www.leadingagile.com/2013/07/agile-health-metrics-for-predictability
- http://salhir.wordpress.com/2011/09/18/agility-health
If your team is having trouble coming up with a velocity or their velocity is varying wildly, it might be time to empower the team to develop some:
2) Agile Discipline.
While this may seem contradictory at first, the most effective Agile teams seem to hum like a fine tuned German sports car. This is similarly achieved via a seemingly Teutonic application of discipline. However, you do not achieve this simply by broad mandate. The discipline should be applied as the team becomes aware of deficiencies. If the team is having difficulty meeting its sprint commitments and as such cannot provide a healthy, consistent velocity, the reaction is often to let up the slack... just extend the iteration. Soon iterations go from two to three then to four weeks. In the mean time evidence of progress toward the release goals is further delayed. Instead of lengthening the iteration, shorten it. Ask the team what it can commit to delivering in a week. You don't have to release every week, but the team should have produced release ready solutions in that time. Run four-to-six one week iterations and you and your team will very quickly develop a predictable velocity from which you can begin to more accurately extrapolate real progress toward completion or begin to see what other steps might be needed to improve.
Similarly, I often see teams that have a scrum/standup every day, perhaps multiple times a day, but they are still disorganized. Efforts may be duplicated, progress and blockers may go unseen, and no one may really know how close we are to 'done' let alone what the next highest priority item to work on is. This is often due to an overloading of the Scrum. Instead of quick team sync up, they become a catch all, rapidly devolving into half to hour long design discussions, requirements gathering, bug reports or ad hoc planning sessions. Again the time-box is your friend. Have the scrum master limit the scrums to fifteen minutes. Anything not relevant to the standard team sync questions of a stand-up or scrum should be tabled for discussion after. Not only does this allow team members to get back to work, it also quickly brings to light related issues which can actually greatly improve the delayed discussions.
Further more, set limited, regular meetings for grooming, planning, the showcase and your retro with clear outcomes for each. Grooming should produce estimable stories with clear acceptance criteria, planning should produce an estimated commitment of delivery of some of these well defined stories and the showcase should clearly demonstrate how the acceptance criteria of each have been delivered. Obviously, each requires the previous one starting with the grooming session(s). Therefore making a rule that a grooming session must conclude with a percentage of the considered stories defined is helpful. To facilitate this I have sometime even set time limits on discussion of stories. 5 minutes per story. If it is not enough the team can vote to extend 5 more minutes or to push the story back in the queue. At the very least this drives progress towards story definition. Even if a story cannot be fully defined due to externally missing information, the team is more aware of the scope and caveats of the story than they were before. Moreover, this is all documented in the even partially groomed story. The alternative is no documentation, no progress, a long discussion ending with a bunch of questions and looks of confusion on the team's faces. Worse yet, the team gets to planning and nothing is understood well enough to commit to and the planning session is postponed.
Here are further details on some Agile disciplines:
3) Regular Retrospectives.
For a team trying to get into a productive groove with Agile, the retrospective is the single most important Agile ceremony. Think of it like a professional sports team taking the time to regularly watch and critique their last game. If they don't do this, all they are doing is playing game after game and improvement is almost accidental. By taking even a short bit of time to call out one or two areas to improve upon for their next game or iteration, a team makes steady, focused improvements. This can be a powerful way to eliminate the most deleterious bad habits/practices and replace them with the habits which will make your teams deliver and succeed.
More on Retros:
2) Agile Discipline.
While this may seem contradictory at first, the most effective Agile teams seem to hum like a fine tuned German sports car. This is similarly achieved via a seemingly Teutonic application of discipline. However, you do not achieve this simply by broad mandate. The discipline should be applied as the team becomes aware of deficiencies. If the team is having difficulty meeting its sprint commitments and as such cannot provide a healthy, consistent velocity, the reaction is often to let up the slack... just extend the iteration. Soon iterations go from two to three then to four weeks. In the mean time evidence of progress toward the release goals is further delayed. Instead of lengthening the iteration, shorten it. Ask the team what it can commit to delivering in a week. You don't have to release every week, but the team should have produced release ready solutions in that time. Run four-to-six one week iterations and you and your team will very quickly develop a predictable velocity from which you can begin to more accurately extrapolate real progress toward completion or begin to see what other steps might be needed to improve.
Similarly, I often see teams that have a scrum/standup every day, perhaps multiple times a day, but they are still disorganized. Efforts may be duplicated, progress and blockers may go unseen, and no one may really know how close we are to 'done' let alone what the next highest priority item to work on is. This is often due to an overloading of the Scrum. Instead of quick team sync up, they become a catch all, rapidly devolving into half to hour long design discussions, requirements gathering, bug reports or ad hoc planning sessions. Again the time-box is your friend. Have the scrum master limit the scrums to fifteen minutes. Anything not relevant to the standard team sync questions of a stand-up or scrum should be tabled for discussion after. Not only does this allow team members to get back to work, it also quickly brings to light related issues which can actually greatly improve the delayed discussions.
Further more, set limited, regular meetings for grooming, planning, the showcase and your retro with clear outcomes for each. Grooming should produce estimable stories with clear acceptance criteria, planning should produce an estimated commitment of delivery of some of these well defined stories and the showcase should clearly demonstrate how the acceptance criteria of each have been delivered. Obviously, each requires the previous one starting with the grooming session(s). Therefore making a rule that a grooming session must conclude with a percentage of the considered stories defined is helpful. To facilitate this I have sometime even set time limits on discussion of stories. 5 minutes per story. If it is not enough the team can vote to extend 5 more minutes or to push the story back in the queue. At the very least this drives progress towards story definition. Even if a story cannot be fully defined due to externally missing information, the team is more aware of the scope and caveats of the story than they were before. Moreover, this is all documented in the even partially groomed story. The alternative is no documentation, no progress, a long discussion ending with a bunch of questions and looks of confusion on the team's faces. Worse yet, the team gets to planning and nothing is understood well enough to commit to and the planning session is postponed.
Here are further details on some Agile disciplines:
- http://redpoint.github.io/RedpointWay/feedback_loops.html
- http://redpoint.github.io/RedpointWay/time_box.html
3) Regular Retrospectives.
For a team trying to get into a productive groove with Agile, the retrospective is the single most important Agile ceremony. Think of it like a professional sports team taking the time to regularly watch and critique their last game. If they don't do this, all they are doing is playing game after game and improvement is almost accidental. By taking even a short bit of time to call out one or two areas to improve upon for their next game or iteration, a team makes steady, focused improvements. This can be a powerful way to eliminate the most deleterious bad habits/practices and replace them with the habits which will make your teams deliver and succeed.
More on Retros:
- http://agile.dzone.com/articles/%E2%80%9C-4-questions%E2%80%9D-retrospective
- http://agileretrospectivewiki.org/index.php?title=Retrospective_Plans
- http://redpoint.github.io/RedpointWay/retrospectives.html
Thursday, June 12, 2014
Agile - O, be some other name!
 |
| Shakespeare's Romeo & Juliet |
Once one grows past the phase where one is simply trying to teach the practices of a particular flavor of Agile Methodologies, one is often faced with the decision of whether to drop using the moniker 'Agile'. If one sees the raw potential within the practices and principles to transform organizational culture to be healthier, happier and more efficient, how do you sell it beyond the IT department? Some leverage broader terms such as Organizational Development, others reframe the term to something like "Agility".
I see the appeal of these approaches and use them myself when appropriate. However, I am often struck that we are just superficially engaging in word play. We are left with Juliet's quandary (Act 2 Scene 2 Line 43): What's in a name? That which we call an Agile Team, by any other name would be as healthy.
Which brings us to the true focus of the more advanced Agile Coach - to transform the team's or organization's health so that they can be, among other things, agile. For this reason I like to embrace the baggage of the term Agile. It is a handle we can use to enter into a transformative conversation. This sort of conversation is usually had at the start of a relationship with a client or potential client. It might not even be had by an Agile Coach, but rather by a Salesperson. I am a firm believer that successful transformations begin at the very first engagement. Why not utilize the power of this handle to begin the transformation?
Rather than telling the person what Agile is, ask what they know about Agile; what they think it is. This can get into all manner of discussion quickly. Even misconceptions can be used as transformative opportunities. You can get quickly past lengthy and potentially boring or confusing explanations and start delving into where they are struggling and suggesting how you can assist them. If you use another name, you have to spend too much valuable conversation time just setting the stage.
Friday, May 9, 2014
... its like eating an apple
I was communicating with the owner of a client company where I am doing an Agile Transformation today when she said basically that to her Agile was all about reviewing, organizing and prioritizing things in bites... a bite at a time... I wanted to clarify to make sure that she understood much of the key is using the tight feedback loops available in iterative development; not just simply iterating. In response I continued the analogy - of eating an apple:
A bite at a time that gives you more info about the rest of the apple, is it juicy and sweet? Tart? Have worms? Rotten? But it is also taking that info and making decisions around the further eating of the apple... Should it be cut unto slices? Cooked in a pie? Can we cut out the bad part and keep the rest?
Or should we leave the apple at good enough and toss the rest in the compost pile while we go back to the fruit bowl for another piece of fruit?
A bite at a time that gives you more info about the rest of the apple, is it juicy and sweet? Tart? Have worms? Rotten? But it is also taking that info and making decisions around the further eating of the apple... Should it be cut unto slices? Cooked in a pie? Can we cut out the bad part and keep the rest?
Or should we leave the apple at good enough and toss the rest in the compost pile while we go back to the fruit bowl for another piece of fruit?
Monday, January 27, 2014
Milwaukee Agile Meetup - Continuous Integration Panel Discussion Summary
Last week I had the pleasure of being on a panel discussion about Continuous Integration at the Milwaukee Agile Meetup. My fellow panelists were Carl Schrammel, Adam Black, Jason Duff, James Carpenter and Adam Johnson.
The discussion grew out of the group's growing interest in this area and challenges that individuals and teams attending the Meetup had expressed recently. I know several people who said they had wanted to attend, so I thought I would post a summary of the discussion.
Q: What does Continuous Integration mean to you? When were you first introduced to the concept and how did it change your perspective?
A: After the initial text book definition was given ("Continuous integration (CI) is the practice, in software engineering, of merging all developer working copies with a shared mainline several times a day." - Wikipedia), the group continued to express their take on CI.
The panel agreed that in order to get the buy in to do more advanced levels of CI requires the building of trust, something familiar to Agile Coaches and leaders everywhere. However, even the most rudimentary CI practices can provide excellent data and feedback which, if communicated properly, can facilitate the building of that trust. Due to the fact that CI can generate data about the health of the deliverable every time a change is made, it can be one of the most powerful and prolific sources of data for information radiators. The trick as with all data is to mine it for the most relevant information to the message you wish to communicate.
Q: Who owns CI? Who sponsors/drives for CI?
A: The panelists seemed to generally agree that in most large project teams, there was a dedicated Operations team in charge of maintaining the CI tools (build servers, repositories, deployments and deployment automation, ci servers, etc). However, many expressed how this could lead to the negative effects of siloing. Panelists shared their experiences with teams who used various means to combat this. Rotation of members into the ops team, rotation of ops duties among teams, the use of embedded testers to serve as the bridge between dev and ops, and use of separate scrum-of-scrums to coordinate dev teams with ops.
We did not get too much into the sponsors for CI. I would suggest, as with trying to get buy in, any individuals or groups who feel they would get a benefit out of the use of CI could sponsor it. I have seen CI started as an engineering initiative and I have also seen it sponsored by Project Management and even Product Owners.
Q: Of those doing CD, has anyone automated the signoff process in tightly controlled organization/industry?
A: No one had seen full blown automated sign-off at the level of the typical product owner, upper management deployment committee. However, several had seen groups who had automated sign-off at lower levels, such as moderate UAT sign-off. This can help pave the way to make the manual sign-off at the executive level easier once trust has been established through a record of reliable test/dev/pass/sign-off cycles.
The evening flew by and that was about all we were able to get to. Prior to the discussion, David Neuman from Redpoint Technologies sent out a list of questions to the panelists that would serve to seed the discussion. I think we hit most of the items tangentially. If anyone would like to discuss them further, leave a comment or email me.
The last question on the list asked if there was one recommendation we have for successfully implementing and leveraging CI.
Build Automated Tests. Even if you still have to trigger your builds or other steps manually, having automated test suites that you can run against your built code is one of the most powerful tools to start getting an ROI on your CI efforts. Furthermore, many of the behaviors and practices of CI which are difficult to master initially revolve around disciplines of TDD. If you have automated tests, it is easier to start to instill these disciplines in your team. As some of the other panelists and I were discussion after the meetup, automated TDD is fun... it makes coding like a game with almost instant gratification to our problem/puzzle solving efforts. Making something fun can really make developing good habits to support it easier.
The discussion grew out of the group's growing interest in this area and challenges that individuals and teams attending the Meetup had expressed recently. I know several people who said they had wanted to attend, so I thought I would post a summary of the discussion.
Q: What does Continuous Integration mean to you? When were you first introduced to the concept and how did it change your perspective?
A: After the initial text book definition was given ("Continuous integration (CI) is the practice, in software engineering, of merging all developer working copies with a shared mainline several times a day." - Wikipedia), the group continued to express their take on CI.
- CI is a powerful feedback tool for both engineering as well as project management - reduces surprises due to integration and deployments and makes the ones which occur more manageable.
- The benefits of CI are best reaped via automation, but even manual CI can bring great improvement.
- CI can help build confidence in the product and the team - one always knows the state of the code at the end of the day.
The distinction between Continuous Integration and Continuous Delivery (CD) was also drawn... with Continuous Delivery being an advanced practice where a team is able to deploy changes to production with high frequency.
Q: What tools are being used?
A: The standard list of revision repositories, build servers, testing frameworks, continuous integration servers, deployment automation were quickly run through - basically if you are interested in CI there is likely a set of tools readily available for your language/tech stack of choice. It was noticed, however, that there are software products and systems which are not necessarily easy to integrate automation or other CI tools too. Particularly these tend to be configuration based systems, or closed systems which perhaps try to manage revision control internally - preventing access or control by external ci/build/test setups. This led to the discussion that aside from tools, the other aspect of CI is the practices and behaviors. These behaviors are often harder to implement than the tools. However, if the behaviors are embraced by a team, even the most simplistic of CI tooling can become powerful. The further consensus of the panel was that it is best to start simply - implementing behaviors and supporting tooling gradually. In this way, each advancement should be lauded as a positive win in the right direction rather than disappointment at not having achieved an elusive ideal CI or CD state in one try.
Q: How to prove the value of CI to developers? to business/product owners? how soon can one expect to see value?
A: The answers to this echoed some of the previous discussion. The general feeling was to take each instance in a case-by-case basis and look for opportunities to introduce behaviors and tools pragmatically to provide greater insight into specific areas where a team may be experiencing pain. Examples: recurring bugs, painful massive code integrations, lost code, misunderstood and mis-implemented user requirements, painful coordination/integration with other systems/teams on deployment, out of sync versions of code between environments (Prod getting ahead of Dev or Test), not being able to do certain types of testing. All of these were brought up as pain points which some degree of CI could have alleviated.
Since CI sits on the front lines of ever changing code, the positive impact of CI can be seen very quickly (as soon as one build cycle in some cases). The key is to communicate this to the parties who would most appreciate the benefit. This is where a CI server can help by providing dashboards and automated messaging, but even utilizing the low tech approach of holding stake-holder meetings before and after a CI 'event' can shed light on the benefit of the activity.
The panel agreed that in order to get the buy in to do more advanced levels of CI requires the building of trust, something familiar to Agile Coaches and leaders everywhere. However, even the most rudimentary CI practices can provide excellent data and feedback which, if communicated properly, can facilitate the building of that trust. Due to the fact that CI can generate data about the health of the deliverable every time a change is made, it can be one of the most powerful and prolific sources of data for information radiators. The trick as with all data is to mine it for the most relevant information to the message you wish to communicate.
Q: Who owns CI? Who sponsors/drives for CI?
A: The panelists seemed to generally agree that in most large project teams, there was a dedicated Operations team in charge of maintaining the CI tools (build servers, repositories, deployments and deployment automation, ci servers, etc). However, many expressed how this could lead to the negative effects of siloing. Panelists shared their experiences with teams who used various means to combat this. Rotation of members into the ops team, rotation of ops duties among teams, the use of embedded testers to serve as the bridge between dev and ops, and use of separate scrum-of-scrums to coordinate dev teams with ops.
We did not get too much into the sponsors for CI. I would suggest, as with trying to get buy in, any individuals or groups who feel they would get a benefit out of the use of CI could sponsor it. I have seen CI started as an engineering initiative and I have also seen it sponsored by Project Management and even Product Owners.
Q: Of those doing CD, has anyone automated the signoff process in tightly controlled organization/industry?
A: No one had seen full blown automated sign-off at the level of the typical product owner, upper management deployment committee. However, several had seen groups who had automated sign-off at lower levels, such as moderate UAT sign-off. This can help pave the way to make the manual sign-off at the executive level easier once trust has been established through a record of reliable test/dev/pass/sign-off cycles.
The evening flew by and that was about all we were able to get to. Prior to the discussion, David Neuman from Redpoint Technologies sent out a list of questions to the panelists that would serve to seed the discussion. I think we hit most of the items tangentially. If anyone would like to discuss them further, leave a comment or email me.
The last question on the list asked if there was one recommendation we have for successfully implementing and leveraging CI.
Build Automated Tests. Even if you still have to trigger your builds or other steps manually, having automated test suites that you can run against your built code is one of the most powerful tools to start getting an ROI on your CI efforts. Furthermore, many of the behaviors and practices of CI which are difficult to master initially revolve around disciplines of TDD. If you have automated tests, it is easier to start to instill these disciplines in your team. As some of the other panelists and I were discussion after the meetup, automated TDD is fun... it makes coding like a game with almost instant gratification to our problem/puzzle solving efforts. Making something fun can really make developing good habits to support it easier.
Wednesday, January 22, 2014
Agile Martial Arts to Prevent The Project K.O.
When training in martial arts, one comes to learn that one of the most powerful tools one has in dealing with an adversary is to control distance and time. One can either increase distance in order to give one more time to analyze and deal with an adversary's attack or one can reduce distance and/or time to limit your adversary's options and ability to develop an attack.
Similarly on a project, surprises are seldom a good thing. However one cannot know everything which is going to happen. Change management strategies have evolved to try to deal with this, however, traditionally these have been largely reactive... like a novice at Close distance flailing wildly to block each attack. So how do you control time/distance to problem fallout on a project?
This is done via the use of feedback loops of varying frequency. Feedback loops of lower frequency can give you the time to "step back" and assess changes before rushing in. This can called a Distance/Time giving action since they give you more time to assess a developing problem, but that means they may also allow the problem to develop further. Feedback loops of higher frequency allow you to address issues immediately, preventing them from ballooning into larger problems or even implementing proactive solutions to stop the problem in its tracks. These are Distance/Time takers, since they shorten the time allowed for a problem to develop. The number and roles of individuals who receive and deal with the feedback initially also plays a part in whether a technique is more giving or taking in nature. Generally, lower number of individuals whose roles are closer to the source of the problem will be a taking action, while the converse is more of a giving action.
Some Distance/Time giving techniques (lower frequency loops):
- Daily scrums/standups
- Iterative development/delivery
- Regular demos
- Regular retrospectives
- Pairing
Taking a step back to gain distance and time is one of the simplest defense moves. Appreciation of the different threat levels each distance presents and the ability to back-out to a safe distance is something which is taught to beginners. Similarly, the techniques for gaining Distance/Time in Agile Development are simple enough that any team can begin to use them right away.
For example, a team is following a more traditional project management approach with few touch points across the team. Perhaps the PM only reports to a board the status of things as dates for delivery of milestones occur. At this point, it is usually too late and if a problem has occurred, the PM is delivering the surprise bad-news. Even worse, a milestone is delivered only to have the product owners report all the surprise deficiencies. Obviously, both of these are uncomfortable for all involved and panic may often set in. By establishing short, frequent and regular meetings with the team including all stakeholders, a team can get the opportunity to see the problems coming and properly deal with them. They are effectively giving themselves the time to deal with the problems rather than rushing headlong into the fray.
A recent client complained that historically, every time they tried to do a deployment the tools the development team used seemed to create surprise errors. Moreover, items were added to the new environment without the client's prior knowledge. These would not necessarily break anything, but they did add confusion and wasted time. In order to address this we established regular meetings with tech leads, the deployment lead, the clients and testing. At the meeting, proposed pending changes were discussed. A draft-deploy was reviewed for surprise dependencies which might be pulled in by the deploy tool. Team members who previously never spoke to one another now communicate regularly around a problem they were all experiencing from different perspectives. Out of this, the team has developed a much more rigorous deployment practice, surprises have been eliminated, and all parties have gained a much better understanding of their deployment tools and an appreciation for each others difficulties in deployment. It is not as much a typical Change Management/Approval board as it is an opportunity for the interested parties to communicate. Meetings never last more than half an hour and usually are about fifteen minutes, but we meet at least once a week. While not one of the traditional Agile Team Meetings, it follows the spirit of frequent cross-communication which is so vital to the Agile Approach.
Some Distance/Time taking techniques (high frequency loops):
- Automated Testing
- Test Driven Development
- Acceptance Criteria/Tests
- Test First Development
- Pairing
- Continuous Integration
- Daily scrums/standups
Distance/Time taking techniques are usually more advanced in Martial arts as they require a bit more training and discipline to do safely. So too in software development. Most of the ones I listed here obviously employ development practices which software engineers will need to hone if they have not done them before. However, once proficiency is obtained in them, these practices can be life savers and even keep at bay the dreaded pager. Utilized well, these operate as a means of clinching problems by stopping them well before they develop into much larger problems in a more devastating environment. Use of Automated testing with a modern CI server can not only identify problems in with new code early on, it can also help make sure that once a bug is fixed, it stays fixed. One of the mantras on a team I was on was "Find a Bug, Write a Test." Basically, whenever a bug was reported, the developer wrote a test for how the solution was supposed to behave. Of course, until the bug was fixed, the test would continue to break. However, the bug would likely never resurface again since our test coverage of our code had now improved. This of course requires the developer discipline of running tests before committing, as well as a Test-First mentality. Without those disciplines the team is back to reactive flailing.
These techniques do not always stop problems from occurring, but like the clinch, they can prevent the problem from developing into a more lethal one. A team with good CI, TDD, and Acceptance testing practices for instance, can deal with and minimize the impact of major architectural changes or even severe problems introduced by changes in third-party software. They can tackle the severe problem in manageable chunks at a level of relative safety.
I listed daily scrums and pairing under both because depending upon the situation these techniques can act both to give time to deal with potentially developing problems as well as to stop problems from starting in the first place through open communication. The latter is usually the case where someone either states what they are working on or having difficulty with and someone else on the team either gives them a solution or can help them avoid pitfalls they have experienced before. As it happens at such a frequent schedule, the time for problems to develop is often completely eliminated - effectively clinching the problems. Scrums and Pairing as time gaining operate in the sense that by approaching problems as a team tends to prevent us from making rash decisions.
A final note: you will notice that I do not say Pair Programming... while I like Pair Programming, many of my colleagues have noted that pairing is a powerful tool for all team members. I have seen PM's, BA's testers, even Product Owners pair on deliverables with great results.
Subscribe to:
Posts (Atom)