Showing posts with label processes. Show all posts
Showing posts with label processes. Show all posts
Friday, June 1, 2007
Can CMMI and Agile play well together?
Brad Appleton on his ACME Blog has a very extensive list of links that say "YES". As a follower of CMMI in the past, this will be interesting reading to me to see what others are thinking.
Wednesday, April 25, 2007
Where does QA fit within Agile?
Like many development shops that have been around doing Traditional Waterfall development over the years, we have a separate department called Quality Assurance. This team consisted of non-developer types that focused primarily with ensuring quality of the product through testing activities. In our case, because we have legacy products that have been developed in technologies that don't lend itself well toward test automation, these testing activities were largely done manually. Unlike the unit-level testing that was done by the developers, the QA team primarily focused on overall system testing. This included test verification of current requirements but also a fair amount of regression testing (again manually done) to ensure that
past functionality continued to work.
As with Waterfall development, QA was largely involved late in the process. Once developers felt their code was completed, they would "throw in over the wall" to QA for testing. QA would do their initial testing, and submit bugs for things not working. Until the overall product was stable enough to give to our customers (through several release cycles), it would go through several fix/build cycles. How long this would go was highly unpredictable, and therefore would cause much frustration if our initial test estimates were too far off.
A couple of years ago, I attended the local Northwest Software Quality Conference here in Portland, Oregon. This is an excellent conference and while anybody in the software industry can get something useful out of it, the primary audience are people involved in QA. As Agile started to heat up in the software industry, presentations started to show up in every conference. Given this audience however, very few had even heard much of Agile and for those that did, weren't using Agile practices. Why? Because Agile assumed (at least at that time) that the testing role and other QA activities were just another hat that developers wore. So for those that had heard of Agile, they were resistant because they feared their jobs in the long run.
I was seeing that same reaction from my own QA group, and was dealing with how to best transition that group into a valuable role of an Agile team. After many sessions with both developers and QA, I started to see the light of how QA could fill some holes that the teams were having. So, here's how QA will look in our organization:
1) QA integrated into every team - Each member of the QA team is now co-located with the Development instead of being in a separate department.
2) QA plays Testing Manager role - QA is responsible for helping the team identify how we know when a story or task is "done". They define done by developing tests with the team that ANYBODY can run including the QA person. They also determine how best to implement that test (manual or automated, which tools, etc.)
3) QA plays Process Improvement Manager role - QA is now going to lead retrospectives at the end of iterations and releases with the team. They will ensure that there is just enough process for the team to ensure quality but not too much that the team doesn't see value in the process. They are also to ensure that all action items from the retrospective get reflected in the work in future iterations and releases.
With these three implementations, we hope to build more quality into the entire process and ensure quality earlier and often in the process. While anybody can wear the Tester hat, now QA has a much broader role in ensuring quality beyond just testing.
past functionality continued to work.
As with Waterfall development, QA was largely involved late in the process. Once developers felt their code was completed, they would "throw in over the wall" to QA for testing. QA would do their initial testing, and submit bugs for things not working. Until the overall product was stable enough to give to our customers (through several release cycles), it would go through several fix/build cycles. How long this would go was highly unpredictable, and therefore would cause much frustration if our initial test estimates were too far off.
A couple of years ago, I attended the local Northwest Software Quality Conference here in Portland, Oregon. This is an excellent conference and while anybody in the software industry can get something useful out of it, the primary audience are people involved in QA. As Agile started to heat up in the software industry, presentations started to show up in every conference. Given this audience however, very few had even heard much of Agile and for those that did, weren't using Agile practices. Why? Because Agile assumed (at least at that time) that the testing role and other QA activities were just another hat that developers wore. So for those that had heard of Agile, they were resistant because they feared their jobs in the long run.
I was seeing that same reaction from my own QA group, and was dealing with how to best transition that group into a valuable role of an Agile team. After many sessions with both developers and QA, I started to see the light of how QA could fill some holes that the teams were having. So, here's how QA will look in our organization:
1) QA integrated into every team - Each member of the QA team is now co-located with the Development instead of being in a separate department.
2) QA plays Testing Manager role - QA is responsible for helping the team identify how we know when a story or task is "done". They define done by developing tests with the team that ANYBODY can run including the QA person. They also determine how best to implement that test (manual or automated, which tools, etc.)
3) QA plays Process Improvement Manager role - QA is now going to lead retrospectives at the end of iterations and releases with the team. They will ensure that there is just enough process for the team to ensure quality but not too much that the team doesn't see value in the process. They are also to ensure that all action items from the retrospective get reflected in the work in future iterations and releases.
With these three implementations, we hope to build more quality into the entire process and ensure quality earlier and often in the process. While anybody can wear the Tester hat, now QA has a much broader role in ensuring quality beyond just testing.
Monday, February 19, 2007
An Agile Approach to adopting Agile
Several years ago, we started our quest towards a better way to develop software. In the process I discovered Extreme Programming or better known as XP. Though I liked many of the concepts that I was learning about, I definitely had my reservations on parts of it. However, the largest reservation I had was that it seemed that the founders and proponents of XP were requiring that this methodology was an "all or nothing" type of approach. If you didn't incorporate all of XP, you really would not benefit from the results that others have had with XP. In fact, some would say that you might actually experience worse results than Waterfall with a partial implementation.
This worried me greatly because I knew that past attempts of trying to implement an entire methodology had failed. Why? Too much to take on too fast. What I found interesting is at least for XP they were taking a Waterfall approach to adopting Agile. Instead, why not take an incremental and evolutionary approach to the adoption? Start with the highest priority items, incorporate them, get feedback on their adoption, and made improvements as needed. Continue this process at a pace that your organization can handle. Ultimately deciding how much agile is enough for your organization at any point of time.
At the same time this was going on, I had an interesting discussion with a colleague. He had told me he hated the idea of methodologies. Why? Because it makes the assumption that you can go buy a tool belt full of tools and assumes that you will not only use all of the tools but will know which tool should be used for which purpose. His approach? Find the tools you need that resolves the issues you need when you need them. To better find the tools you do need to spend the time understanding what tools are available and how to use them. However, it is important to note that knowing and using are two different things. Just carry the minimal tools that you need to get the job done. His approach was much more Agile in my opinion and one based on adopting a set of Best Practices than adopting entire Methodologies.
I eventually found the answer to our problems. One of the "founders" of Agile, Alistair Cockburn, had a "methodology" called Crystal Clear. Unlike others, it really wasn't a methodology but a discussion on what practices are available from XP, Scrum, FDD, and others. He truly advocated the "cut-and-paste" approach, find something that is close to what you need and put it into your own processes. Then, make it your own! He also advocated the incremental approach, at least start with SOMETHING than it will take a life of its own. He focused more on educating the reasons behind each of the practices, and being able to sell it to others through your own adoption.
This approach allowed us to explore all other methodologies as Best Practices to find the right set of tools for our tool belt at a pace where it can be learned and truly understood. If you are struggling with Agile, chances are you are going too fast and taking on too much. Slow it down and take the Agile approach. Do only the minimum of what it takes to address the highest priority issues you are dealing with. Then tackle the next one, and the next one, and so forth.
What's funny is that the founders of each of these methodologies took the same approach. They started out with something, then realized that something else was needed until they came out with a set of "somethings" that worked for their particular situation. They found a pattern as they continue to implement in different companies, and thus they developed their particular methodology. They took the incremental and evolutionary approach. They customized it through constant feedback and changes to make it work for them - for their cultures, their people, and the technologies and products they were developing. You have to do the same thing in your journey towards adoption!
Though this approach, we have grown to appreciate what each of the methodologies bring to the table. However, we had to learn what we were missing to truly appreciate what we could get with each of the Best Practices. In other words, we had to realize that we needed a particular tool to accomplish the job much better than the tools that we currently had in our possession. Bottom line, most implementation of processes fail because of lack of understanding. Either understanding of why they are valuable or understanding of how they can be used for your particular needs. If you don't know how to use a hammer, and you don't know why you would use a hammer, you probably aren't going to find the hammer that useful. Think about that for a moment!
This worried me greatly because I knew that past attempts of trying to implement an entire methodology had failed. Why? Too much to take on too fast. What I found interesting is at least for XP they were taking a Waterfall approach to adopting Agile. Instead, why not take an incremental and evolutionary approach to the adoption? Start with the highest priority items, incorporate them, get feedback on their adoption, and made improvements as needed. Continue this process at a pace that your organization can handle. Ultimately deciding how much agile is enough for your organization at any point of time.
At the same time this was going on, I had an interesting discussion with a colleague. He had told me he hated the idea of methodologies. Why? Because it makes the assumption that you can go buy a tool belt full of tools and assumes that you will not only use all of the tools but will know which tool should be used for which purpose. His approach? Find the tools you need that resolves the issues you need when you need them. To better find the tools you do need to spend the time understanding what tools are available and how to use them. However, it is important to note that knowing and using are two different things. Just carry the minimal tools that you need to get the job done. His approach was much more Agile in my opinion and one based on adopting a set of Best Practices than adopting entire Methodologies.
I eventually found the answer to our problems. One of the "founders" of Agile, Alistair Cockburn, had a "methodology" called Crystal Clear. Unlike others, it really wasn't a methodology but a discussion on what practices are available from XP, Scrum, FDD, and others. He truly advocated the "cut-and-paste" approach, find something that is close to what you need and put it into your own processes. Then, make it your own! He also advocated the incremental approach, at least start with SOMETHING than it will take a life of its own. He focused more on educating the reasons behind each of the practices, and being able to sell it to others through your own adoption.
This approach allowed us to explore all other methodologies as Best Practices to find the right set of tools for our tool belt at a pace where it can be learned and truly understood. If you are struggling with Agile, chances are you are going too fast and taking on too much. Slow it down and take the Agile approach. Do only the minimum of what it takes to address the highest priority issues you are dealing with. Then tackle the next one, and the next one, and so forth.
What's funny is that the founders of each of these methodologies took the same approach. They started out with something, then realized that something else was needed until they came out with a set of "somethings" that worked for their particular situation. They found a pattern as they continue to implement in different companies, and thus they developed their particular methodology. They took the incremental and evolutionary approach. They customized it through constant feedback and changes to make it work for them - for their cultures, their people, and the technologies and products they were developing. You have to do the same thing in your journey towards adoption!
Though this approach, we have grown to appreciate what each of the methodologies bring to the table. However, we had to learn what we were missing to truly appreciate what we could get with each of the Best Practices. In other words, we had to realize that we needed a particular tool to accomplish the job much better than the tools that we currently had in our possession. Bottom line, most implementation of processes fail because of lack of understanding. Either understanding of why they are valuable or understanding of how they can be used for your particular needs. If you don't know how to use a hammer, and you don't know why you would use a hammer, you probably aren't going to find the hammer that useful. Think about that for a moment!
Wednesday, February 14, 2007
Are you ready for Agile?
Paul Klipp, a guest author at Agile Advice (one of my favorite blogs on Agile), poses a question to those thinking about Agile with his post entitled, "To be or not be Agile". Here's his introduction:
He further gets down the heart and soul of agile with this statement:
So, are you ready to be agile or not? Read more of his post to decide.
At it's core, an agile process is designed to address a long-standing problem with traditional development methods: scope-creep. Most traditional processes begin with a thorough description of the desired product and then code until it's done. The weakness of these approaches is that in the event of a change in the business need or a reevaluation of the plan, much work can be lost and deadlines can easily slip out of control, and costs with them. The traditional way to address this problem is with change documents. A change document basically is a way of telling the customer what it will cost to make a change to the plan after development is underway. Agile processes are designed to do away with the cost of change so that the client is free to evolve the system under construction toward the ideal end goal, even if it is a moving target.
He further gets down the heart and soul of agile with this statement:
The beauty of iterative development combined with continuous integration is that if we approach a piece of software with the intention of working until all features are done (traditional approach), then at no point in the project is there usable code except at the end. Whereas with iterative development, the client can pull the plug at any time and have a working product, even if not fully-featured. For example, halfway through a large, waterfall or RAD (Rapid Application Development) style project we might have had a working administrative interface but not working user interface, or no user authentication system; in other words, a fundamentally flawed and unusable product. Halfway through an agile Project (at the end of any iteration) we have a product which, though lacking some intended features, actually had all the essential components of a software tool finished, tested, and ready to deploy if desired. The customer is not married to the project and the developers can't hold the project hostage until the bitter end; If it concludes early, the investment is not a sunk cost.
So, are you ready to be agile or not? Read more of his post to decide.
Friday, February 9, 2007
Early observations around projects
As my previous post may have indicated, we became focused on heavy processes around software development and project management. We tried to manage these processes around tools. We did have moderate success around projects. However, we also had some fantastic failures. Here were some early observations that I had with those projects. At the time, I didn't know how to resolve them but I was able to find some interesting patterns. Here is the list of my top 10:
1) Traditional Waterfall assumes that you can figure out as much as possible early in the process. What's ironic is that we also understood the Cone of Uncertainty, which states that the reliability of estimates will become greater as you move through the process. We learned that we couldn't plan or predict the unexpected. We could prepare somewhat through risk management but not necessarily prevent things from happening.
2) Shorter range projects (less than 6 months) were more successful in meeting deadlines than larger range projects. It seemed the larger the project the harder it was to stay on track.
3) Projects that involved internal resources outside of the Development group were more successful than projects that didn't. These resources included Sales, Marketing, Technical Support, Customer Training, etc.
4) Projects that involved some interaction with outside customers were more successful than solely internal representatives.
5) Changes were harder and more resistant to make later in the process because it meant reinvesting a lot of time going upstream in the process. The process assumed that you wouldn't have to do a lot of that. Because of this, we would deliver functionality that the customer really wanted something different with the promise that we would look at it in the future (but rarely did).
6) Because of that, customers and/or customer representatives would ask for anything they could think of whether or not they really needed it because there was no other opportunity to do so.
7) Most of the projects involved managers who felt they had to have control over the project - control over what each resources worked on, control over what the customers could have, control over what stakeholders should know. However, on those rare projects where the manager was more transparent, more accommodating, and empowered the team to determine how they do the work and what work they should do; we found that everybody was happier, more motivated and produced better results.
8) Tools to manage projects became harder to use because it assumed that the work breakdowns, dependencies, resources allocated would hardly change and that the only thing that would change is time. That was rarely the case, and project managers found themselves managing the tool instead of the project itself.
9) It was assumed that estimates were reliable from those that provided it. Therefore, all milestones were expected to be hit by the stakeholders even though how we had figured out the milestones was very uncertain. Projects that were similar to those in the past fared better than those that were different. Most projects fell into the latter category and involved either domain or technical experience that was new to at least one member of the team at any time.
10) Though we had documentation for things such as requirement specification, technical design, etc, we found that as the process moved along those didn't reflect reality. It became too time consuming for people to go back to the documents. Therefore, the working solution and code behind it were the only thing that people could count on. We had thought that documentation were be used as a reference for future projects, but instead weren't used. Also, the documentation wasn't always developed by the team but many times passed around. Therefore, there were many disconnects because of misinterpretation of the documentation. These disconnects caused many of the bugs and incorrect solutions that caused much fix and test cycles as well as go back and fix the incorrect solutions sometime after the solution has been provided to the customer through a production release.
Even though we saw these patterns, and knew that something was wrong with our processes and approach to both software development and project management, we assumed that we were using the processes or tools wrong. It took us some time to finally figure out that perhaps the processes and tools were the culprit.
We started to look around to see if others were experiencing the same thing. And, that's how we discovered Agile...
1) Traditional Waterfall assumes that you can figure out as much as possible early in the process. What's ironic is that we also understood the Cone of Uncertainty, which states that the reliability of estimates will become greater as you move through the process. We learned that we couldn't plan or predict the unexpected. We could prepare somewhat through risk management but not necessarily prevent things from happening.
2) Shorter range projects (less than 6 months) were more successful in meeting deadlines than larger range projects. It seemed the larger the project the harder it was to stay on track.
3) Projects that involved internal resources outside of the Development group were more successful than projects that didn't. These resources included Sales, Marketing, Technical Support, Customer Training, etc.
4) Projects that involved some interaction with outside customers were more successful than solely internal representatives.
5) Changes were harder and more resistant to make later in the process because it meant reinvesting a lot of time going upstream in the process. The process assumed that you wouldn't have to do a lot of that. Because of this, we would deliver functionality that the customer really wanted something different with the promise that we would look at it in the future (but rarely did).
6) Because of that, customers and/or customer representatives would ask for anything they could think of whether or not they really needed it because there was no other opportunity to do so.
7) Most of the projects involved managers who felt they had to have control over the project - control over what each resources worked on, control over what the customers could have, control over what stakeholders should know. However, on those rare projects where the manager was more transparent, more accommodating, and empowered the team to determine how they do the work and what work they should do; we found that everybody was happier, more motivated and produced better results.
8) Tools to manage projects became harder to use because it assumed that the work breakdowns, dependencies, resources allocated would hardly change and that the only thing that would change is time. That was rarely the case, and project managers found themselves managing the tool instead of the project itself.
9) It was assumed that estimates were reliable from those that provided it. Therefore, all milestones were expected to be hit by the stakeholders even though how we had figured out the milestones was very uncertain. Projects that were similar to those in the past fared better than those that were different. Most projects fell into the latter category and involved either domain or technical experience that was new to at least one member of the team at any time.
10) Though we had documentation for things such as requirement specification, technical design, etc, we found that as the process moved along those didn't reflect reality. It became too time consuming for people to go back to the documents. Therefore, the working solution and code behind it were the only thing that people could count on. We had thought that documentation were be used as a reference for future projects, but instead weren't used. Also, the documentation wasn't always developed by the team but many times passed around. Therefore, there were many disconnects because of misinterpretation of the documentation. These disconnects caused many of the bugs and incorrect solutions that caused much fix and test cycles as well as go back and fix the incorrect solutions sometime after the solution has been provided to the customer through a production release.
Even though we saw these patterns, and knew that something was wrong with our processes and approach to both software development and project management, we assumed that we were using the processes or tools wrong. It took us some time to finally figure out that perhaps the processes and tools were the culprit.
We started to look around to see if others were experiencing the same thing. And, that's how we discovered Agile...
Thursday, February 8, 2007
When processes were my passion
It's interesting what others will say when you start something new or describe who you are and what you do. I have really appreciated the support so far and thank those that have mentioned this blog. One of them (who shall remain nameless) referred to this blog being more about processes than people. Actually, as you will discover as we go along, while processes are talked about the emphasis will be more about what is around those processes. In other words, processes will not be the core of the discussion.
However, there was a time when I was a process junkie. As I have found with many managers in my industry, I came up the ranks. I started as a programmer, and my manager saw some leadership qualities in me and was looking for a manager to handle daily operations while he spent time focusing on future initiatives. One thing led to another, and I began my journey from the programming world into management.
I didn't know how to be a manager at first, so like I did with programming I looked to others for advice. I didn't go to school and learn about management. So, I looked at what others were using as "tools" in the industry. As I had done with programming, I had assumed that if I just find a framework it will get me much faster to becoming a good manager. So, I went looking for a framework.
After some searching, I found some frameworks out there that seemed to be prominent at the time (this was in the late 90s). In particular, I found SEI's Capability Maturity Model (now CMMI) for software development and PMI's Project Management Book of Knowledge (PMBOK). These were THICK books full of processes. I had thought I had died and went to heaven! I couldn't wait to take this framework and apply it right away. And I did just that.
In later posts, I will get into more details of how I think about these frameworks now. For now, let's just say it didn't go well. I quickly learned that you can't just push process on people, especially if you don't really understand the concepts, values, and principles behind those processes. I was looking for process as a short-cut as well as a way to have better control of things as a young manager establishing myself. Instead, I came off as a young, cocky manager who had no idea of what he was doing and in the process making life miserable for those around him. People who used to like me as a programmer thought that the manager job had gone to my head. And you know what? I started believing it myself.
I know there are other managers who believe that if you put heavy formal processes, procedures, policies, etc. that you will be considered a great manager and that things are so structured and disciplined that anybody can do that job. These are the managers who talk in terms of subordinates. I quickly learned that I didn't want to become that kind of manager. It really wasn't my style, and I needed to find "tools" that supported what my strengths were as a manager. While at the same time, allowing those that I manage to play to their particular strengths. Also realizing that whatever was to be in place for processes needed some flexibility for the unpredictability that the future brings and would provide an environment that would not stifle creativity and innovation.
So, am I the "process guy"? Not anymore, I'm proud to say. If you could put any label on me, I guess you could call me the "enabler guy". I figure out how teams and individuals can become better. If they are better, my job is easier. If they are better, the company is more successful. Now why wouldn't I want those things as a manager?
However, there was a time when I was a process junkie. As I have found with many managers in my industry, I came up the ranks. I started as a programmer, and my manager saw some leadership qualities in me and was looking for a manager to handle daily operations while he spent time focusing on future initiatives. One thing led to another, and I began my journey from the programming world into management.
I didn't know how to be a manager at first, so like I did with programming I looked to others for advice. I didn't go to school and learn about management. So, I looked at what others were using as "tools" in the industry. As I had done with programming, I had assumed that if I just find a framework it will get me much faster to becoming a good manager. So, I went looking for a framework.
After some searching, I found some frameworks out there that seemed to be prominent at the time (this was in the late 90s). In particular, I found SEI's Capability Maturity Model (now CMMI) for software development and PMI's Project Management Book of Knowledge (PMBOK). These were THICK books full of processes. I had thought I had died and went to heaven! I couldn't wait to take this framework and apply it right away. And I did just that.
In later posts, I will get into more details of how I think about these frameworks now. For now, let's just say it didn't go well. I quickly learned that you can't just push process on people, especially if you don't really understand the concepts, values, and principles behind those processes. I was looking for process as a short-cut as well as a way to have better control of things as a young manager establishing myself. Instead, I came off as a young, cocky manager who had no idea of what he was doing and in the process making life miserable for those around him. People who used to like me as a programmer thought that the manager job had gone to my head. And you know what? I started believing it myself.
I know there are other managers who believe that if you put heavy formal processes, procedures, policies, etc. that you will be considered a great manager and that things are so structured and disciplined that anybody can do that job. These are the managers who talk in terms of subordinates. I quickly learned that I didn't want to become that kind of manager. It really wasn't my style, and I needed to find "tools" that supported what my strengths were as a manager. While at the same time, allowing those that I manage to play to their particular strengths. Also realizing that whatever was to be in place for processes needed some flexibility for the unpredictability that the future brings and would provide an environment that would not stifle creativity and innovation.
So, am I the "process guy"? Not anymore, I'm proud to say. If you could put any label on me, I guess you could call me the "enabler guy". I figure out how teams and individuals can become better. If they are better, my job is easier. If they are better, the company is more successful. Now why wouldn't I want those things as a manager?
Subscribe to:
Posts (Atom)