In a recent conversation, a technical manager I had just met was describing to me how agile is not a fixed form - it's the ability to change the shape of the organisation to the needs of the time. That's what it means to be agile - to adapt.
With his hands, he indicated his two ideal shapes - the triangle, with its implied hierarchical management approach, & the circle, which encloses the whole team. Sometimes, you need to have a structure, but sometimes you need to flatten it out & work together.
Those two shapes don't just describe the team, but also the delivery pattern. The traditional waterfall model starts at a point to build solely on that, then, when the point (call it project inception) is correct, a larger layer is built (project definition), etc. That triangle could be considered upside-down, but it is the same basic shape.
An agile circle shows how the project is iterative - it produces something today, but continuous integration suggests that this is the state of the whole project being delivered at each sprint, becoming more complete in functionality, but a whole throughout. You should always see the big picture as the goal of each sprint, with functionality being contributions to the whole. When you are building your triangle, layer on layer, each layer is a complete goal in itself.
The reason some people devolve to waterfall models is because they say that the client understands twaterfall better. A client will pay for a fully delivered stage, rather than paying for 50% of the functionality. I don't think the client has the problem here - it's in the way that the project is represented to the client. Unless the client is determined to axe the project if the design (for example) isn't up to scratch, they are effectively committed to the deliverable - they want the outcome.
Managing the client's expectations - keeping them informed & taking their feedback - is a key component of agile, & is supposed to make the whole project management aspect both more client-friendly & less likely to give the client a surprise than the "big drop" of a waterfall project completion. Hiding project status from the client is not only not agile, but sounds like bad business.
Some even hide an agile internal process behind a waterfall delivery system - intentionally keeping the client in the dark. Again, this is not really agile.
So, what's the answer - what shape should your project be in? I think you can take the De Bono approach. When he uses six frames to solve problems, he provides a framework for simply focusing on different aspects of the problem, without prejudice or preconceptions. With practice, you can look at any project & say "Where is the waterfall-ness here?" "In what way are we being agile?" "How is our process differing from pure scrum?"
By all means, use your fingers to make the shape & "look through" that frame to see your project or your team differently, if that helps to expand your vision; but remember that it doesn't change the project in any way. To make changes - process improvements, better client engagement, quality, repeatability, etc - you have to go beyond the circle & the triangle & operate in the third dimension - effort.
Tuesday, December 17, 2013
Sunday, August 26, 2012
Testing Times
There comes a time in every project's life when the big release is due, which may involve user acceptance testing that doesn't fit into the Scrum (or Agile) methodology - that is, it must be done at the end of the project. No matter how much regression testing & continuous integration you've employed along the way, there will need to be formal reports or documentation that satisfies the customer's (or the company's) need for waterfall processes.
It is at this point that you suddenly realise that you have a hole in your process.
The team structure that has worked so well for so long throughout the project - one tester feeding off a handful of developers - falls in a heap because all of the developers need to do testing, but they don't know the tools or the test process. The tester now becomes the bottleneck & doesn't have time to do any testing themselves because they're busy running around getting everyone up to speed.
Productivity plummets. Questions get asked about potential slippages or how to deal with the issues raised as a result of testing. The methodology is under fire & under stress, as is the team, the scrum master, & personal sanities.
Do not despair!
(or, in the words of the Immortal Douglas Adams - "Don't Panic!")
This is not the end of the world, merely the release of the product. Potentially, it's the end of the project (dependent on how you do such things). At the very least, now is the time to learn from the experience & work out how to do it better next time - & that doesn't mean going back to the way things used to work - because things usually didn't.
Move forward! Train! Share the load & responsibility - & ownership - of the whole process. So what if you forgot to count the release process in your general development procedures. You will next time, because you're agile. That's the point - not getting it right first time is a good thing - it means you have room to learn & improve. Getting it right first time means it was very obvious (not interesting), or else you've missed something fundamental (far more likely). It will hit you when you least expect it. That's OK, because you're agile enough to deal with the problem when it happens (rather than trying to plan for all eventualities up front).
Product release or project completion is not the end of the world, & shouldn't be treated as a threat to the methodology. These things were meant to try us, but they are short-lived testing times.
It is at this point that you suddenly realise that you have a hole in your process.
The team structure that has worked so well for so long throughout the project - one tester feeding off a handful of developers - falls in a heap because all of the developers need to do testing, but they don't know the tools or the test process. The tester now becomes the bottleneck & doesn't have time to do any testing themselves because they're busy running around getting everyone up to speed.
Productivity plummets. Questions get asked about potential slippages or how to deal with the issues raised as a result of testing. The methodology is under fire & under stress, as is the team, the scrum master, & personal sanities.
Do not despair!
(or, in the words of the Immortal Douglas Adams - "Don't Panic!")
This is not the end of the world, merely the release of the product. Potentially, it's the end of the project (dependent on how you do such things). At the very least, now is the time to learn from the experience & work out how to do it better next time - & that doesn't mean going back to the way things used to work - because things usually didn't.
Move forward! Train! Share the load & responsibility - & ownership - of the whole process. So what if you forgot to count the release process in your general development procedures. You will next time, because you're agile. That's the point - not getting it right first time is a good thing - it means you have room to learn & improve. Getting it right first time means it was very obvious (not interesting), or else you've missed something fundamental (far more likely). It will hit you when you least expect it. That's OK, because you're agile enough to deal with the problem when it happens (rather than trying to plan for all eventualities up front).
Product release or project completion is not the end of the world, & shouldn't be treated as a threat to the methodology. These things were meant to try us, but they are short-lived testing times.
Wednesday, August 22, 2012
RingTFM
I've been in this industry a long time, & back in the dark old days of Unix running on DEC boxes locked away in rooms where the acolytes tended their gods lovingly, when the bitch operator from hell was a serial as funny as it was relevant, one of the first & most important acronyms I learned was RTFM - that is, kindly refer back to the manual. Yes, I know it stands for much more than that, but there is no need to go on about the importance of the F, otherwise we're probably going to get distracted with references to the Kama Sutra, being the only FM I've ever read.
Anyway, my point is that it was the right way to do things then, & even in today's world of instant gratification, RingTFM can be edifying. It settles arguments, gives inspiration & guidance, & gets you unstuck. It is the oracle (to get back to that religious experience) (not to be confused with the software company).
But why am I talking about the FM in a blog ostensibly about Scrum? Simply put, there is an FM, & it should be Red. Scrum is a thinking methodology - it requires you to be aware of the process & constantly review what you are doing, what you are achieving, & how you can do more or better. You can't just "be" Scrum by following a set of procedures. It's in the development of the procedures that the power of Scrum comes to the fore. It is in the ownership, the review, the practice, the understanding, the doing, that counts for success.
Failure is more likely linked to not being Scrum. That's a big call. Scrum cannot, of itself, fail, because it is a methodology. There will always be a way to make Scrum-like practices. There will be better practices. There will be places where more practices can be applied, or the same practices will be more effective, but it will be very hard to find an environment where Scrum just will not work. That statement is actually wrong - because Scrum will never work unless the people involved want it to.
The only way that Scrum can be made to work is if people understand what Scrum is (& isn't), & how they contribute to its success (rather than expecting a silver bullet - proven since the sixties to not exist, much to the delight of vampyres everywhere). By people, I mean everyone, as Scrum is all-inclusive. Senior management down to build-boy (the recent graduate or part-timer) must RTFM. This is not just the responsibility of the Scrum Master - they are simply the person most likely to notice when there's a deviation from Scrum, but it's not their job to be the repository of all methodology knowledge to save anyone else from RingTFM.
Anyway, my point is that it was the right way to do things then, & even in today's world of instant gratification, RingTFM can be edifying. It settles arguments, gives inspiration & guidance, & gets you unstuck. It is the oracle (to get back to that religious experience) (not to be confused with the software company).
But why am I talking about the FM in a blog ostensibly about Scrum? Simply put, there is an FM, & it should be Red. Scrum is a thinking methodology - it requires you to be aware of the process & constantly review what you are doing, what you are achieving, & how you can do more or better. You can't just "be" Scrum by following a set of procedures. It's in the development of the procedures that the power of Scrum comes to the fore. It is in the ownership, the review, the practice, the understanding, the doing, that counts for success.
Failure is more likely linked to not being Scrum. That's a big call. Scrum cannot, of itself, fail, because it is a methodology. There will always be a way to make Scrum-like practices. There will be better practices. There will be places where more practices can be applied, or the same practices will be more effective, but it will be very hard to find an environment where Scrum just will not work. That statement is actually wrong - because Scrum will never work unless the people involved want it to.
The only way that Scrum can be made to work is if people understand what Scrum is (& isn't), & how they contribute to its success (rather than expecting a silver bullet - proven since the sixties to not exist, much to the delight of vampyres everywhere). By people, I mean everyone, as Scrum is all-inclusive. Senior management down to build-boy (the recent graduate or part-timer) must RTFM. This is not just the responsibility of the Scrum Master - they are simply the person most likely to notice when there's a deviation from Scrum, but it's not their job to be the repository of all methodology knowledge to save anyone else from RingTFM.
Thursday, August 9, 2012
Kicking the Goals
Too often, especially in modern society, we are goal-oriented. Usually, that means having your eyes on a goal (or even having a goal), & continually moving towards it. This minimises deviations from the path, & tends to increase the probability of achieving goals. In theory, this is a reasonable thing to do, but in practice, how do you implement it.
If you have a goal, what is the process of reaching it? How do you know that the goal is getting nearer or farther away? How do you notice if the goal-posts change? Are there any pit-falls on the way?
These questions can only be answered by focusing on the journey - the process - rather than the goal.
The process is important, because it's yours - you define it, you control it. In fact, if you have no control over the goal (only the setting of it), then the process is the only place where your actions take effect. Each of your actions has a consequence. This may achieve a positive or negative effect with regards you reaching your goal. Sometimes the distance to the goal still may not be measurable, but at least if you're concentrating on where you place each foot-step, your direction, your environment, etc, you are less likely to trip or take a wrong turn - or lose the path entirely.
Focusing on the process is useful - it gives you something to 'do' that you have control over. You can get better at achieving goals by becoming aware of how you have achieved them in the past, & learning from that experience - which paths are more likely to be rough or even, what environments are more likely to be adverse.
Total focus on how to achieve the goal, rather than what goal to achieve, or what it looks like, is far more likely to come up with success. That success is an overall one, not necessarily relating to this goal, but in achieving goals in general.
Whether the goal relates to increasing sales, improving a product, or simply achieving a better work environment, simply wanting the goal is not enough - the process of achieving a goal is everything. It's time to change focus & look at the process. It's time to concentrate on picking up the ball & running with it. It's time for kicking the goals.
If you have a goal, what is the process of reaching it? How do you know that the goal is getting nearer or farther away? How do you notice if the goal-posts change? Are there any pit-falls on the way?
These questions can only be answered by focusing on the journey - the process - rather than the goal.
The process is important, because it's yours - you define it, you control it. In fact, if you have no control over the goal (only the setting of it), then the process is the only place where your actions take effect. Each of your actions has a consequence. This may achieve a positive or negative effect with regards you reaching your goal. Sometimes the distance to the goal still may not be measurable, but at least if you're concentrating on where you place each foot-step, your direction, your environment, etc, you are less likely to trip or take a wrong turn - or lose the path entirely.
Focusing on the process is useful - it gives you something to 'do' that you have control over. You can get better at achieving goals by becoming aware of how you have achieved them in the past, & learning from that experience - which paths are more likely to be rough or even, what environments are more likely to be adverse.
Total focus on how to achieve the goal, rather than what goal to achieve, or what it looks like, is far more likely to come up with success. That success is an overall one, not necessarily relating to this goal, but in achieving goals in general.
Whether the goal relates to increasing sales, improving a product, or simply achieving a better work environment, simply wanting the goal is not enough - the process of achieving a goal is everything. It's time to change focus & look at the process. It's time to concentrate on picking up the ball & running with it. It's time for kicking the goals.
Wednesday, August 8, 2012
The Class System
There I was, in the middle of modifying by hand several hundred files in my IDE, which I'd found from a search, but I had to replace the thing I'd searched for, & then change a part of the next two or three lines (which varied). I kept thinking that my twenty years IT industry experience was not really being put to the best possible use. I often think at that point "Who can I get to waste their time in my place?", & I generally don't have an answer.
This is a part of the democratisation of software development. Agile methodologies, in particular, demand that all contributors to the product development process have equal value - almost regardless of experience. This is a wonderful ideal that many people don't see the practicality of - that is, ownership is shared, & you are effectively producing quality output for your own benefit, not for someone else's.
This is all well & good until you expect a recent graduate to understand the intricacies of enterprise architecture or a new person on the team to estimate the time it will take for a bugfix. Experience within the team (independent of industry experience) has to be 'worth' something. It has to be considered valuable. If it has value, then it should be treated as valuable, & therefore the more mindless tasks should be foisted on others - like contractors, who should be considered short-term & not worth training, & juniors, who need to learn through experience.
The increasingly short attention span of youth, if you'll allow me to turn crusty, & instant gratification of online learning does not mean that experience no longer has value. It means that it is under-appreciated.
This is wrong.
Once upon a time, young boys were apprenticed to masters of their trade for many years, often at their parents' expense, with the expectation that learning the trade would thereafter set them up for life. The master's approach was that a young boy needed to learn the ropes by doing simple things that didn't directly contribute to the trade - just to gain experience in what the trade was about. The classic examples coming right up to the modern age including sending the apprentice to get the lunches, or to the local hardware to buy tools (with the associated jokes).
Those days are dying. When it comes to the more skilled employment of professionals, from doctors & lawyers to engineers, the education received away from the professional environment makes the new apprentice more mature (sometimes well into their twenties), & self-assured. That is, they think they already know everything. Wisdom suggests that they know nothing until they are placed at the disposal of a master, but most university graduates have never been taught wisdom.
Toiling through my collection of files to modify, I could give up & write a script of some kind to perform this one-off modification. To me, at my time of life, this sounds like a bit of a waste of time. For an apprentice, it would be a wonderful learning experience, & I wouldn't care if it took them twice as long to complete than simply performing the manual task - they'll get better at it, & better at assessing whether it's worth it to write the script. In the process, they'll get exposed to the process. This is what apprentices do.
We tend to forget, sometimes, that a graduate engineer has no experience & very little skill in the industry. They are a blank canvas, a potential to contribute to the organisation, either directly or through assisting a master engineer. They are not an instant professional. They should not be encouraged to think that they are.
Although I can't see the old trade designations - apprentice/journeyman/master being applied to software development, we have had the concepts lying around the whole time - junior dev/dev/senior dev - & yet those meanings have fallen by the wayside. We lack structure in our approach to product development, which is a reflection of agile approaches, which tend to encourage more fluid structures. In fact, they don't advocate such structures, but some people have taken their own laziness & agile's lack of application to these areas as a good enough reason to no longer be vigilant about what goes on around the product development process. By all means, allow the team to direct itself as a group of professionals, but someone - management - needs to ensure that the professionalism rises to its true potential & the organisation benefits from agility.
There we have the next problem - management's essential role in ensuring that, outside of developing the product, someone is making sure that the organisation is on track, the community within it is alive & well & growing, across all of its parts. In essence, those working at the coal-face don't have the time or energy to think about such things, & they never have. Those who produce, using the resources (capital) provided by management, need leadership to achieve their goals. They need strategies. They need someone of a different class - outside of their day-to-day - to direct.
Democracy amongst equals is all well & good, but a true society needs the benefits of the class system.
This is a part of the democratisation of software development. Agile methodologies, in particular, demand that all contributors to the product development process have equal value - almost regardless of experience. This is a wonderful ideal that many people don't see the practicality of - that is, ownership is shared, & you are effectively producing quality output for your own benefit, not for someone else's.
This is all well & good until you expect a recent graduate to understand the intricacies of enterprise architecture or a new person on the team to estimate the time it will take for a bugfix. Experience within the team (independent of industry experience) has to be 'worth' something. It has to be considered valuable. If it has value, then it should be treated as valuable, & therefore the more mindless tasks should be foisted on others - like contractors, who should be considered short-term & not worth training, & juniors, who need to learn through experience.
The increasingly short attention span of youth, if you'll allow me to turn crusty, & instant gratification of online learning does not mean that experience no longer has value. It means that it is under-appreciated.
This is wrong.
Once upon a time, young boys were apprenticed to masters of their trade for many years, often at their parents' expense, with the expectation that learning the trade would thereafter set them up for life. The master's approach was that a young boy needed to learn the ropes by doing simple things that didn't directly contribute to the trade - just to gain experience in what the trade was about. The classic examples coming right up to the modern age including sending the apprentice to get the lunches, or to the local hardware to buy tools (with the associated jokes).
Those days are dying. When it comes to the more skilled employment of professionals, from doctors & lawyers to engineers, the education received away from the professional environment makes the new apprentice more mature (sometimes well into their twenties), & self-assured. That is, they think they already know everything. Wisdom suggests that they know nothing until they are placed at the disposal of a master, but most university graduates have never been taught wisdom.
Toiling through my collection of files to modify, I could give up & write a script of some kind to perform this one-off modification. To me, at my time of life, this sounds like a bit of a waste of time. For an apprentice, it would be a wonderful learning experience, & I wouldn't care if it took them twice as long to complete than simply performing the manual task - they'll get better at it, & better at assessing whether it's worth it to write the script. In the process, they'll get exposed to the process. This is what apprentices do.
We tend to forget, sometimes, that a graduate engineer has no experience & very little skill in the industry. They are a blank canvas, a potential to contribute to the organisation, either directly or through assisting a master engineer. They are not an instant professional. They should not be encouraged to think that they are.
Although I can't see the old trade designations - apprentice/journeyman/master being applied to software development, we have had the concepts lying around the whole time - junior dev/dev/senior dev - & yet those meanings have fallen by the wayside. We lack structure in our approach to product development, which is a reflection of agile approaches, which tend to encourage more fluid structures. In fact, they don't advocate such structures, but some people have taken their own laziness & agile's lack of application to these areas as a good enough reason to no longer be vigilant about what goes on around the product development process. By all means, allow the team to direct itself as a group of professionals, but someone - management - needs to ensure that the professionalism rises to its true potential & the organisation benefits from agility.
There we have the next problem - management's essential role in ensuring that, outside of developing the product, someone is making sure that the organisation is on track, the community within it is alive & well & growing, across all of its parts. In essence, those working at the coal-face don't have the time or energy to think about such things, & they never have. Those who produce, using the resources (capital) provided by management, need leadership to achieve their goals. They need strategies. They need someone of a different class - outside of their day-to-day - to direct.
Democracy amongst equals is all well & good, but a true society needs the benefits of the class system.
Thursday, July 26, 2012
Look Back in Wonder
One of the most important & misunderstood aspects of agile methodologies is review. This has been described in the agile principles fully, & Scrum, in particular, expects that the team review each sprint's achievements (relative to its goals).
Strangely, you would think that people would embrace this part of the process like any other, & yet it seems to be the first one to be threatened from the outside or the inside. From the outside, people in management who don't understand or support agile processes (or product development, I fear) tend to think of all meetings that developers have as being unproductive, by definition, because developers should be chained to their desks, coding. From the inside, developers who don't understand product development tend to think of all meetings that they attend as being unproductive, because developers should be allowed to get on with the coding.
With everyone in agreement, reviews are the first meeting to get dropped from the process.
The big losers are product owners/managers & team/project managers. In both cases, reviews (& meetings in general) are their chief way of communicating - both expressing their views & getting feedback from the development team. Stand up meetings are not enough, because these should be short & to the point. Planning meetings look to the future. So, when do we learn from the past? How do we improve? How do we predict the future (estimate)?
Without review processes in place, the team will stagnate, & the product (& dev team) will lose out.
Once upon a time, CMM (the CMU Maturity Model) was used as a measure of a team's effectiveness. Most of the level differences were onion-skins of auditability - the habit of reviewing the coding, the product produced & delivered, the processes in place, the methodology. Although this kind of "heaviness" of measurement is usually associated with waterfall methodologies, it should never be forgotten that the thing being measured is the maturity of the company/team - their ability to have learned from their experience & apply those learnings to the rest of their lifecycle.
Any form of review should be looked at in terms of what it accomplishes. If it accomplishes nothing, then you are definitely wasting your time. This doesn't mean that you should stop reviewing, but that you should do something different to start reviewing things in a useful way - a way that gives meaning to the team & adds to its maturity. You only get out what you put in. Review your review process to invest it with effectiveness.
Without review, we wander through the product lifecycle with our eyes closed, groping in the self-imposed darkness, hoping that we're heading in the right direction, but incapable of planning the next step or understanding where we've come from. It's time to open the eyes - & all of the senses that we have available to us. It's time to look into the future by understanding the past.
It's time to look back in wonder.
Strangely, you would think that people would embrace this part of the process like any other, & yet it seems to be the first one to be threatened from the outside or the inside. From the outside, people in management who don't understand or support agile processes (or product development, I fear) tend to think of all meetings that developers have as being unproductive, by definition, because developers should be chained to their desks, coding. From the inside, developers who don't understand product development tend to think of all meetings that they attend as being unproductive, because developers should be allowed to get on with the coding.
With everyone in agreement, reviews are the first meeting to get dropped from the process.
The big losers are product owners/managers & team/project managers. In both cases, reviews (& meetings in general) are their chief way of communicating - both expressing their views & getting feedback from the development team. Stand up meetings are not enough, because these should be short & to the point. Planning meetings look to the future. So, when do we learn from the past? How do we improve? How do we predict the future (estimate)?
Without review processes in place, the team will stagnate, & the product (& dev team) will lose out.
Once upon a time, CMM (the CMU Maturity Model) was used as a measure of a team's effectiveness. Most of the level differences were onion-skins of auditability - the habit of reviewing the coding, the product produced & delivered, the processes in place, the methodology. Although this kind of "heaviness" of measurement is usually associated with waterfall methodologies, it should never be forgotten that the thing being measured is the maturity of the company/team - their ability to have learned from their experience & apply those learnings to the rest of their lifecycle.
Any form of review should be looked at in terms of what it accomplishes. If it accomplishes nothing, then you are definitely wasting your time. This doesn't mean that you should stop reviewing, but that you should do something different to start reviewing things in a useful way - a way that gives meaning to the team & adds to its maturity. You only get out what you put in. Review your review process to invest it with effectiveness.
Without review, we wander through the product lifecycle with our eyes closed, groping in the self-imposed darkness, hoping that we're heading in the right direction, but incapable of planning the next step or understanding where we've come from. It's time to open the eyes - & all of the senses that we have available to us. It's time to look into the future by understanding the past.
It's time to look back in wonder.
Wednesday, July 18, 2012
Different Agilities
I've worked in many environments that have adopted a basic concept of "agility", & then gone on to define what they mean by that. In many cases, XP has been the dominant idea, because the methodology comes from the dev team, & XP is very much oriented towards software developers - those with the knowledge, skills, & intelligence - defining their own work practices. Management lets them play their little games & carries on regardless. I've also been exposed to Scrum-influenced environments. I use the term broadly. Someone better qualified than me refers to them as "Scrum-but" - as in, "we follow scrum, but we don't ..."
Once upon a time, I was in the camp that said XP is great for software development, Scrum can have a much broader audience, & agile can be applied in some way to any part of any business. Essentially, though, you have to pick a methodology & stick to it. The more I look at methodologies in isolation (or else in a mix), the more I have come to realise that they're not so incompatible.
I'm not suggesting that XP & Scrum are complementary, for example, but they are not mutually exclusive. There is nothing in one that negates the other. In fact, you might say that, with the same goals, the gaps in best practice that one has is generally an area of focus in the other.
For example, XP is very much around driving the development process from developers' practices - empowering them to ensure that they can contribute to the best of their extraordinary ability. Scrum is more about having a team infrastructure in place for the product development environment that ensures that the product is the best it can be through a whole-team effort. Different focus. Same results.
In the cases of both XP & Scrum, the agile principles are being followed to ensure that time isn't wasted on useless things, the people with the skills concentrate on what they're good at, & that the customer gets a product that they actually want. This is the crux of agility - & what waterfall models could never achieve.
I may be working in a pure Scrum environment, but we're adopting XP-inspired practices to make us stronger. You could say that we are still in XP-but, but we're going forward to become as agile as we can be, learning better ways, reviewing ourselves & our processes. We can only get better by looking at, & adopting, different agilities.
Once upon a time, I was in the camp that said XP is great for software development, Scrum can have a much broader audience, & agile can be applied in some way to any part of any business. Essentially, though, you have to pick a methodology & stick to it. The more I look at methodologies in isolation (or else in a mix), the more I have come to realise that they're not so incompatible.
I'm not suggesting that XP & Scrum are complementary, for example, but they are not mutually exclusive. There is nothing in one that negates the other. In fact, you might say that, with the same goals, the gaps in best practice that one has is generally an area of focus in the other.
For example, XP is very much around driving the development process from developers' practices - empowering them to ensure that they can contribute to the best of their extraordinary ability. Scrum is more about having a team infrastructure in place for the product development environment that ensures that the product is the best it can be through a whole-team effort. Different focus. Same results.
In the cases of both XP & Scrum, the agile principles are being followed to ensure that time isn't wasted on useless things, the people with the skills concentrate on what they're good at, & that the customer gets a product that they actually want. This is the crux of agility - & what waterfall models could never achieve.
I may be working in a pure Scrum environment, but we're adopting XP-inspired practices to make us stronger. You could say that we are still in XP-but, but we're going forward to become as agile as we can be, learning better ways, reviewing ourselves & our processes. We can only get better by looking at, & adopting, different agilities.
Subscribe to:
Posts (Atom)