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.
Sunday, August 26, 2012
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.
Subscribe to:
Posts (Atom)