A good 80-85% of my work since 1991 has been on contract for the federal government here in Ottawa. For those not familiar, Ottawa is Canada's capital and seat of government. There are some 200,000 people in the region that are federal government employees, and nearly as many who are secondarily employed as terms, contractors and consultants or support staff for companies that provide those people. In short, the government is a huge part of business in this town, and I've been part of it for a good long time. In terms of the groups with whom I've worked, I've had ups and downs, seeing the good, bad and ugly of organizations and their management.
Since I first learned about Agile in late 2000 (actually it was Extreme Programming then - the term Agile Software Development wasn't coined until a couple of months later), I've been asked more than a few times if it applies to the public sector. After all, I was told, there really isn't that much change in the business of running the federal bureaucracy!
Really?
Since I first started doing work for the government in 1991, there have been 6 general elections with 2 changes in the ruling party, and one with a new leader (effectively a change in party!). Each of those changes brought major changes in policy and thus legislation. Even after elections in which the ruling party did not change, new policies that were part of the election platform were enacted. There have also been numerous re-organizations of departments and agencies in that time, each of which changes the focus and direction of the business.
In other words, the business changed, sometimes dramatically.
Additionally, there have been external events that have affected the business of government. A group I was with from 2003-2006 works on an immigration system whose raison d'être was the 9/11 attacks. That system was also affected after the 2004 Indian Ocean tsunami when the Immigration Minister quickly created a program to fast-track requests from that area. The development group was able to quickly respond to the required changes and put them into production so that the program could be supported.
All of this illustrates that even in the public sector business change does occur. It can be rapid and disruptive or move at a glacial or tectonic pace. Regardless, it happens and organizations need to be in a position to deal with it. Of course, being a huge proponent of Agile Software Development, this is where I say, "And Agile can help you deal with that change!"
That's true, of course, but I would suggest that where Agile provides the most value for public sector organizations (and arguably all organizations) is not with these macro-level changes but rather with the much smaller changes that occur as a team, group or organization learns what problem they are really trying to solve with an automated system. This occurs on a daily basis - during visioning and chartering exercises, story creation, release planning, iteration planning, daily standup meetings, ad hoc discussions, iteration demos, retrospectives and even after release when more real-world feedback is obtained.
All of what's learned in those opportunities for collaboration is what sets Agile apart from other processes. The ability to quickly apply the new knowledge and get it into the hands of the people who need it is by far the most important factor. This is what pushes the features most required to the top of the priority list. This is what eliminates features that aren't required, and reduces the priority of those that are less important. This is how knowing the Done State of work allows the whole team and project community to understand how long it will take for features to be released. This is how transparent progress on projects allows the organization to better understand and manage their entire portfolio of IT work. This is how an organization can position itself to be proactively ready for the next macro-level change.
And that is agility in the public sector.
Friday, November 20, 2009
Wednesday, November 18, 2009
New Venture!
It has been a while since I've written, and I have a myriad of excuses for that - none of which are valid, and none of which would be considered interesting!
I would like to announce, though, that I am part of a new company called The Agile Consortium. This is a partnership I have formed with Mark Levison and Glenn Waters to provide Agile Software Development Coaching and Training services. We're primarily focusing on the Ottawa region, but are willing and able to travel anywhere that a plane, train and automobile will take us.
As a team, we have a great mix of experience and talent:
If you would like to find out more about our services and how we can help your software development organization to improve, please contact us at info@theagileconsortium.com. A quick chat costs nothing, and we do provide a free 1-hour Agile Benefits presentation.
I would like to announce, though, that I am part of a new company called The Agile Consortium. This is a partnership I have formed with Mark Levison and Glenn Waters to provide Agile Software Development Coaching and Training services. We're primarily focusing on the Ottawa region, but are willing and able to travel anywhere that a plane, train and automobile will take us.
As a team, we have a great mix of experience and talent:
Mark ha
s been an Agile practitioner since 2001, introducing Agile methods one practice at a time inside a small team. Prior to co-founding The Agile Consortium, as an employee of a large ISV he was responsible for introducing Scrum to the organization and coaching a number of teams – including the design of a Test Driven Development strategy and introduction of a number of practices to support it. Mark is also an Agile Editor at InfoQ and has written dozens of articles on Agile topics. He also publishes a popular blog, Notes from a Tool User.
s been an Agile practitioner since 2001, introducing Agile methods one practice at a time inside a small team. Prior to co-founding The Agile Consortium, as an employee of a large ISV he was responsible for introducing Scrum to the organization and coaching a number of teams – including the design of a Test Driven Development strategy and introduction of a number of practices to support it. Mark is also an Agile Editor at InfoQ and has written dozens of articles on Agile topics. He also publishes a popular blog, Notes from a Tool User.Glen
n is a seasoned Technology Executive with over 25 years of expertise in all aspects of the software industry. He has served in developer-coach roles helping to transform large corporations and government organizations to agile methodologies. Glenn has successfully worked with Agile at all levels of an organization from working on teams delivering business software up to introducing Agile methodology to the CIO/CTO offices. Glenn is also a co-founder of the Agile Ottawa Group.
As for me, I'm a veteran Agile Coach with over 20 years industry experience. I've been involved with Agile since 2000, and have helped organizations from pre-funding startups to the Fortune 15 improve their software delivery process. I'm a co-founder of the Agile Ottawa Group, and an active writer, speaker and advocate of agile methods in Canada.
n is a seasoned Technology Executive with over 25 years of expertise in all aspects of the software industry. He has served in developer-coach roles helping to transform large corporations and government organizations to agile methodologies. Glenn has successfully worked with Agile at all levels of an organization from working on teams delivering business software up to introducing Agile methodology to the CIO/CTO offices. Glenn is also a co-founder of the Agile Ottawa Group.
As for me, I'm a veteran Agile Coach with over 20 years industry experience. I've been involved with Agile since 2000, and have helped organizations from pre-funding startups to the Fortune 15 improve their software delivery process. I'm a co-founder of the Agile Ottawa Group, and an active writer, speaker and advocate of agile methods in Canada.If you would like to find out more about our services and how we can help your software development organization to improve, please contact us at info@theagileconsortium.com. A quick chat costs nothing, and we do provide a free 1-hour Agile Benefits presentation.
Tuesday, June 16, 2009
A New Generation, A New Perspective
At the beginning of May I attended the Cutter IT Summit in Cambridge, MA. I quite enjoyed it, since it was not just about Agile but many other aspects of the IT industry. The summit gave me the opportunity to soak in knowledge from many thought leaders from various sectors of IT.
A common theme that I encountered is that we are in the midst of a sea change in IT. The current economic circumstances are certainly a driver of this, with organizations abandoning old business relationships to save incredible amounts of money moving their operational IT work to the cloud, and its natural extension of Software as a Service (SaaS). Indeed, I'm an advisor for (and did a pile of development work with) local social media startup Favequest that is entirely run in that manner.
The other change vector we are seeing is a new generation of people both entering into the IT industry and consuming its services. I'm talking about those kids (which is now anyone more than 5 years younger than me!) who can send text messages from their smartphone while it's still in their pocket. To them, technology is a given - it's always on, always available, and these "kids" have very little brand loyalty. If your product or service no longer appeals to them you're done! Many of the traditional rules of business have been turned upside down.
This reminded me of a presentation I gave at the CUSEC conference in 2005 on Extreme Programming. After giving my talk, I fielded the usual questions. One question, though, absolutely stunned me. A student asserted more than asked that "XP seemed like a very heavyweight process". I hadn't realized that my perspective, and that of those who have been in the IT industry for any more than a few years, had skewed my view of what constituted a lightweight process. In the absence of any other perspective, XP looked very prescriptive and heavyweight to this student. Indeed, most if not all of the development processes that form Agile were reactions to what were perceived by my generation as heavyweight and prescriptive.
The lesson in this, I believe, is that our perception of something is precisely that - our own! We may share that perspective with others who have similar experiences, but we must be judicious in the use of that assumption.
So what, then, will the software development world look like when the Agile methods are indeed heavyweight and prescriptive? I think the App Store is a hint of what's to come. There was also a session accepted for Agile 2009 entitled, Agile's Too Slow: Developing a Facebook App for the Obama Campaign. Finally, at a recent Agile Ottawa gathering, Luc Levesque of TravelPod described the development process his company uses, which includes a deployment to production as soon as a developer commits to source control.
These micro-processes are all predicated on gathering usage statistics and user feedback in near real-time and executing immediately on the results. The business environment can literally change hour to hour, so everything in the process must be geared towards handling that flux. As a business, you simply can't afford to complain that things change - you have to adapt or you'll go out of business.
Essentially, in the always on, always available world even Agile circa 2009 isn't sufficently lightweight. I'm sure there will be those that say micro-processes don't apply to them.
The sea change discussed at the Cutter IT Summit is happening whether we want it to or not. We need, therefore, to decide if we want to ride the wave, get washed away, or just get the hell out of the water altogether. For the latter two cases, there are plenty of young people ready to cast off the burden of our overly prescriptive Agile processes and get down to really delivering some value!
A common theme that I encountered is that we are in the midst of a sea change in IT. The current economic circumstances are certainly a driver of this, with organizations abandoning old business relationships to save incredible amounts of money moving their operational IT work to the cloud, and its natural extension of Software as a Service (SaaS). Indeed, I'm an advisor for (and did a pile of development work with) local social media startup Favequest that is entirely run in that manner.
The other change vector we are seeing is a new generation of people both entering into the IT industry and consuming its services. I'm talking about those kids (which is now anyone more than 5 years younger than me!) who can send text messages from their smartphone while it's still in their pocket. To them, technology is a given - it's always on, always available, and these "kids" have very little brand loyalty. If your product or service no longer appeals to them you're done! Many of the traditional rules of business have been turned upside down.
This reminded me of a presentation I gave at the CUSEC conference in 2005 on Extreme Programming. After giving my talk, I fielded the usual questions. One question, though, absolutely stunned me. A student asserted more than asked that "XP seemed like a very heavyweight process". I hadn't realized that my perspective, and that of those who have been in the IT industry for any more than a few years, had skewed my view of what constituted a lightweight process. In the absence of any other perspective, XP looked very prescriptive and heavyweight to this student. Indeed, most if not all of the development processes that form Agile were reactions to what were perceived by my generation as heavyweight and prescriptive.
The lesson in this, I believe, is that our perception of something is precisely that - our own! We may share that perspective with others who have similar experiences, but we must be judicious in the use of that assumption.
So what, then, will the software development world look like when the Agile methods are indeed heavyweight and prescriptive? I think the App Store is a hint of what's to come. There was also a session accepted for Agile 2009 entitled, Agile's Too Slow: Developing a Facebook App for the Obama Campaign. Finally, at a recent Agile Ottawa gathering, Luc Levesque of TravelPod described the development process his company uses, which includes a deployment to production as soon as a developer commits to source control.
These micro-processes are all predicated on gathering usage statistics and user feedback in near real-time and executing immediately on the results. The business environment can literally change hour to hour, so everything in the process must be geared towards handling that flux. As a business, you simply can't afford to complain that things change - you have to adapt or you'll go out of business.
Essentially, in the always on, always available world even Agile circa 2009 isn't sufficently lightweight. I'm sure there will be those that say micro-processes don't apply to them.
What about life-critical software such as that in medical devices and avionics? What about control systems for nuclear power stations? There's no way we could use a micro-process for embedded software development!Funny, I heard the same questions almost 10 years ago about XP and other Agile processes.
The sea change discussed at the Cutter IT Summit is happening whether we want it to or not. We need, therefore, to decide if we want to ride the wave, get washed away, or just get the hell out of the water altogether. For the latter two cases, there are plenty of young people ready to cast off the burden of our overly prescriptive Agile processes and get down to really delivering some value!
Sunday, June 14, 2009
Rounding the Corners
I was cutting the grass this afternoon and remembered back to when I was a kid. My parents had a relatively large lot, and it used to take me a good two hours to cut the lawn. The problem was, I hated cutting the lawn. Even when I was a teenager, I couldn't understand why we want to "maintain" our lawns, making them look as artificial as possible without resorting to Astroturf.
I would do whatever was possible to get out of cutting the lawn. I still do, for that matter! Raining in Sudbury? Well, it could make it to Ottawa at any time... that would be unsafe! Inevitably, though, I had to cut it.
Even then, I wasn't going to go out of my way to extend my agony any more than was necessary. The back lawn in particular was quite large, and by itself it took a full hour to cut. I guess I have the process improvement gene turned on, because I spent a good amount of that one hour trying to figure out how to make it something less than, well, one hour. Eventually I figured out what slowed me down - square corners. Each 90 degree turns mean stopping, turning the mower starting again. If I could remove as many of those corners as possible, I would reduce the amount of time it took to cut that lawn.
This particular yard wasn't perfectly rectangular, and had several trees. I determined that there were a few places along the edge I could cut first to remove some of the variance in the shape of the yard, and that I would have to do at least one full pass to cleanly cut the outside perimeter (OK, so I did care a bit about the quality as well!). After that, I kept to cutting in one continuous strip that was curved around the corners rather than square. This didn't bother my Dad at all, so I then set about optimizing the new process.
It took a couple of tries, but I eventually reduced the cutting time from a full hour to 45 minutes. Being a rather impatient teenager at the time, having an extra 15 minutes to do what I wanted was much better than nothing!!
This relates to practices in Agile that allow a team to move faster, or at the very least sustain their current velocity. Automating anything that is repetetive, tedious and chews up time goes a long way towards reducing and even eliminating those 90 degree turns. Testing, builds, deployments, etc. are all practices that can be automated and have a tremendous amount of tool support now. These "rounded corners" will keep the team moving ahead at a steady pace.
Oh yeah, after I moved out of my parents' house, my Dad bought a riding mower. Cutting the grass is now considered fun, I'm told. I have never had the opportunity to use the riding mower myself. I'm sure there's another lesson there somewhere! :)
I would do whatever was possible to get out of cutting the lawn. I still do, for that matter! Raining in Sudbury? Well, it could make it to Ottawa at any time... that would be unsafe! Inevitably, though, I had to cut it.
Even then, I wasn't going to go out of my way to extend my agony any more than was necessary. The back lawn in particular was quite large, and by itself it took a full hour to cut. I guess I have the process improvement gene turned on, because I spent a good amount of that one hour trying to figure out how to make it something less than, well, one hour. Eventually I figured out what slowed me down - square corners. Each 90 degree turns mean stopping, turning the mower starting again. If I could remove as many of those corners as possible, I would reduce the amount of time it took to cut that lawn.
This particular yard wasn't perfectly rectangular, and had several trees. I determined that there were a few places along the edge I could cut first to remove some of the variance in the shape of the yard, and that I would have to do at least one full pass to cleanly cut the outside perimeter (OK, so I did care a bit about the quality as well!). After that, I kept to cutting in one continuous strip that was curved around the corners rather than square. This didn't bother my Dad at all, so I then set about optimizing the new process.
It took a couple of tries, but I eventually reduced the cutting time from a full hour to 45 minutes. Being a rather impatient teenager at the time, having an extra 15 minutes to do what I wanted was much better than nothing!!
This relates to practices in Agile that allow a team to move faster, or at the very least sustain their current velocity. Automating anything that is repetetive, tedious and chews up time goes a long way towards reducing and even eliminating those 90 degree turns. Testing, builds, deployments, etc. are all practices that can be automated and have a tremendous amount of tool support now. These "rounded corners" will keep the team moving ahead at a steady pace.
Oh yeah, after I moved out of my parents' house, my Dad bought a riding mower. Cutting the grass is now considered fun, I'm told. I have never had the opportunity to use the riding mower myself. I'm sure there's another lesson there somewhere! :)
Thursday, June 11, 2009
Revert to Training
I was having a "conversation" on Twitter this morning with Esther Derby and Scott Duncan about how good engineering practices are required in addition to Scrum's project management practices.
This isn't anything new - I've blogged about it before.
We discussed how it often seems that it's easier to introduce the management practices of Scrum than the engineering practices of XP. Esther asked me why I thought this was the case, and a thought struck me - it's how the developers were trained.
(Warning - here comes yet another aviation analogy!)
During my flight training, my first instructor made a point of saying early and often that it was very important to listen closely, do what she said the way she said to do it, and to practice that way afterwards. She emphasized the importance of this, saying that "when faced with an emergency, you'll revert to your original training". That was in 2005, and even now I hear her voice in my head when I'm flying and practicing things such as forced landings.
How does this apply to software development? Well, consider the poor overworked software developer. They've had this bloody Scrum process thrust upon them meaning they have to deliver more, deliver it faster and have those annoying business people around all the time to pester them. On top of it, the damned "Agile Coach" is harassing all the developers to write more code that tests the code they've already written. Near the end of the sprint, this poor developer is running out of time and still has work to complete - they are facing an emergency! So what do they do? They revert to their original training.
What was that training? If they went to university or college, likely long hours working alone or in very small groups trying to get assignments done. They hacked something together that met the requirements for the assignment, and could afford to make it throwaway. Automated tests? BAH!! Simplest thing that could possibly work? How's that going to impress the prof? In the end, the attitude is to get something - anything - done in order to get the marks.
It's this training environment that leads to the problems when the developers are "faced with an emergency" later in their careers.
This isn't anything new - I've blogged about it before.
We discussed how it often seems that it's easier to introduce the management practices of Scrum than the engineering practices of XP. Esther asked me why I thought this was the case, and a thought struck me - it's how the developers were trained.
(Warning - here comes yet another aviation analogy!)
During my flight training, my first instructor made a point of saying early and often that it was very important to listen closely, do what she said the way she said to do it, and to practice that way afterwards. She emphasized the importance of this, saying that "when faced with an emergency, you'll revert to your original training". That was in 2005, and even now I hear her voice in my head when I'm flying and practicing things such as forced landings.
How does this apply to software development? Well, consider the poor overworked software developer. They've had this bloody Scrum process thrust upon them meaning they have to deliver more, deliver it faster and have those annoying business people around all the time to pester them. On top of it, the damned "Agile Coach" is harassing all the developers to write more code that tests the code they've already written. Near the end of the sprint, this poor developer is running out of time and still has work to complete - they are facing an emergency! So what do they do? They revert to their original training.
What was that training? If they went to university or college, likely long hours working alone or in very small groups trying to get assignments done. They hacked something together that met the requirements for the assignment, and could afford to make it throwaway. Automated tests? BAH!! Simplest thing that could possibly work? How's that going to impress the prof? In the end, the attitude is to get something - anything - done in order to get the marks.
It's this training environment that leads to the problems when the developers are "faced with an emergency" later in their careers.
Tuesday, May 26, 2009
(Almost) Instant Karma
Recently, a team at a client that had been having success with the managerial practices of Agile was beginning to feel the dull pain of gradually mounting technical debt. The lack of automated tests and a slew of code smells were pointed out, and the developers were quite keen on learning how to apply their new skills for identifying and eliminating debt taught to them by technical coach Mark Levison.
It was pointed out to the team's management and the Customer that there would be some cost to paying down the debt, not unlike the Principal and Interest ratio in a loan payment. While the payment is the same (the length of the iteration), the amount paid as interest (technical debt) gradually becomes less and more is paid towards the principal (stories). This was accepted, although the Customer correctly wanted to be able to at least see what work was being performed to pay down the technical debt.
After this meeting, the development team's manager talked to me. He was concerned that the developers would be spending time trying to make the system "perfect". While I agreed that "good enough" would suffice, I didn't agree with this manager's next assertion: "The system isn't going to be changed after this next bit of work is completed." I pointed out to him that the vast majority of work on a system is performed after it has been released into production, but he still had a lingering concern.
Fast-forward a few days, and I'm notified by this manager that the team is losing one of its developers and half of the time of one of its business analysts. I was not happy, to say the least, and asked why this was happening. The manager said that their last project needed them back to do some new work. I asked, "What new work?". The manager replied, "Some new requirements came up after the users got the system in production."
He didn't seem to understand the irony of the situation.
It was pointed out to the team's management and the Customer that there would be some cost to paying down the debt, not unlike the Principal and Interest ratio in a loan payment. While the payment is the same (the length of the iteration), the amount paid as interest (technical debt) gradually becomes less and more is paid towards the principal (stories). This was accepted, although the Customer correctly wanted to be able to at least see what work was being performed to pay down the technical debt.
After this meeting, the development team's manager talked to me. He was concerned that the developers would be spending time trying to make the system "perfect". While I agreed that "good enough" would suffice, I didn't agree with this manager's next assertion: "The system isn't going to be changed after this next bit of work is completed." I pointed out to him that the vast majority of work on a system is performed after it has been released into production, but he still had a lingering concern.
Fast-forward a few days, and I'm notified by this manager that the team is losing one of its developers and half of the time of one of its business analysts. I was not happy, to say the least, and asked why this was happening. The manager said that their last project needed them back to do some new work. I asked, "What new work?". The manager replied, "Some new requirements came up after the users got the system in production."
He didn't seem to understand the irony of the situation.
Wednesday, May 20, 2009
Agile Project Management Public Course - July 28-29, 2009
Mayford Technologies will be holding a 2-day public Agile Project Management course in Ottawa, ON on Tuesday, July 28 and Wednesday, July 29, 2009. For this session we're offering summer special pricing of $995.
The course provides an overview of Agile Development, and allows the participants to understand its background, motivation, and benefits. They will learn how to manage and track Agile Development projects, and strategies for introducing Agile Development to their organization.
Registration is limited, so sign up today!
The course provides an overview of Agile Development, and allows the participants to understand its background, motivation, and benefits. They will learn how to manage and track Agile Development projects, and strategies for introducing Agile Development to their organization.
Registration is limited, so sign up today!
Subscribe to:
Posts (Atom)
Posts
