Here is the Youtube video if you prefer :)
Messages
Bon sens!
Il y a 15 ans
25 avril 2011
INVEST in Good Stories, and SMART Tasks
Here is the Youtube video if you prefer :)
20 juillet 2010
17 mai 2010
Subordinating the Scrum Team
From http://www.leadingagile.com/2010/05/subordinating-scrum-team.html
Agilists intuitively get that it's a bad idea to build an inventory of detailed specs way ahead of when they are going to get turned into software. Why? Because we know that as our product emerges, we are going to want to make changes to those requirements. There is a real risk that a lot of that work will end up being waste. That's a big part of why we document agile requirements as user stories... we want the placeholder now, but we don't need the details until we get closer to building that part of the product. It keeps our options open and our overhead low.
Building an inventory of requirements has a more insidious impact than just opening up the possibility of waste. Sure, we risk specifying stuff that the business might not need, but we also build in assumptions and risk that can't be validated. Everything that we define now, everything that can't be built and tested immediately after specification, represents something that we'll have to validate or mitigate somewhere down the road. Those uncertainties make it really hard to forecast when we are going to get to done. They make it tough to be predictable.
Furthermore, requirements gathering an analysis shouldn't be done in a vacuum. We know that we're going to want some help from our development team to discuss what's possible from a technology perspective. When we pull our team into meetings to discuss these things, we are taking their attention away from the task at hand. Our team is working on the highest priority features, and here we are pulling them away to help forecast lower priority requirements that may or may not ever make it into the product. It's a pretty solid formula for going slower than we have to.
Even though we may have some capacity to do the requirements work... and it would be nice to get ahead of the game a little... it is not something we generally do on agile projects. Managing all those requirements changes, tracking all those assumptions and risks, and absorbing all the productivity impact to the development team is just too great a cost. We KNOW it is going to cause us problems down the road. Any benefits we'd gain from getting ahead of the requirements work would be lost due to the overhead necessary to maintain our requirements inventory. That inventory slows us down and makes us more resistant to change.
We understand... in this kind of a scenario... that the team has to subordinate the requirements gathering process to the overall production cadence of the delivery team.
Now, let's extend this metaphor up a little and talk about our financial services company... and specifically our new hyper-productive Credit Card Processing Scrum team. With regard to the rest of the organization... our Scrum team is able to produce working software much faster than everyone else around them. The question we're dealing with is... SHOULD they produce working software much faster than everyone else around them? In this context, under this set of circumstances, I'm saying no.
I'm suggesting that the Scrum team in our complex product organization becomes very much like the requirements gathering function in our earlier example.
When the Credit Card Processing team builds software features faster than the rest of the organization can consume those features, they risk the possibility of waste and rework. They introduce assumptions and risks that have to be managed and mitigated throughout the life of the project. They will disrupt the other development teams around them and force those teams to multi-task. The other teams will be forced to pay attention to features that they won't be ready to build for another several months. All that code will slow us down and make us resistant to change.
While it is technically possible for the Credit Card Processing team to get a head of the game... and it might make them feel more productive... it might be great for their team morale... ask yourself what impact they are having on the rest of the organization. It might not be as positive as you think. So... for all the same reasons you might ask a PO or a BA to slow down writing requirements to fill the product backlog, you might want to ask your Scrum team to slow down building software until the rest of the organization can catch up.
It's counter-intuitive, but if you start thinking past the single team, it might be exactly what you need to do.
Agilists intuitively get that it's a bad idea to build an inventory of detailed specs way ahead of when they are going to get turned into software. Why? Because we know that as our product emerges, we are going to want to make changes to those requirements. There is a real risk that a lot of that work will end up being waste. That's a big part of why we document agile requirements as user stories... we want the placeholder now, but we don't need the details until we get closer to building that part of the product. It keeps our options open and our overhead low.
Building an inventory of requirements has a more insidious impact than just opening up the possibility of waste. Sure, we risk specifying stuff that the business might not need, but we also build in assumptions and risk that can't be validated. Everything that we define now, everything that can't be built and tested immediately after specification, represents something that we'll have to validate or mitigate somewhere down the road. Those uncertainties make it really hard to forecast when we are going to get to done. They make it tough to be predictable.
Furthermore, requirements gathering an analysis shouldn't be done in a vacuum. We know that we're going to want some help from our development team to discuss what's possible from a technology perspective. When we pull our team into meetings to discuss these things, we are taking their attention away from the task at hand. Our team is working on the highest priority features, and here we are pulling them away to help forecast lower priority requirements that may or may not ever make it into the product. It's a pretty solid formula for going slower than we have to.
Even though we may have some capacity to do the requirements work... and it would be nice to get ahead of the game a little... it is not something we generally do on agile projects. Managing all those requirements changes, tracking all those assumptions and risks, and absorbing all the productivity impact to the development team is just too great a cost. We KNOW it is going to cause us problems down the road. Any benefits we'd gain from getting ahead of the requirements work would be lost due to the overhead necessary to maintain our requirements inventory. That inventory slows us down and makes us more resistant to change.
We understand... in this kind of a scenario... that the team has to subordinate the requirements gathering process to the overall production cadence of the delivery team.
Now, let's extend this metaphor up a little and talk about our financial services company... and specifically our new hyper-productive Credit Card Processing Scrum team. With regard to the rest of the organization... our Scrum team is able to produce working software much faster than everyone else around them. The question we're dealing with is... SHOULD they produce working software much faster than everyone else around them? In this context, under this set of circumstances, I'm saying no.
I'm suggesting that the Scrum team in our complex product organization becomes very much like the requirements gathering function in our earlier example.
When the Credit Card Processing team builds software features faster than the rest of the organization can consume those features, they risk the possibility of waste and rework. They introduce assumptions and risks that have to be managed and mitigated throughout the life of the project. They will disrupt the other development teams around them and force those teams to multi-task. The other teams will be forced to pay attention to features that they won't be ready to build for another several months. All that code will slow us down and make us resistant to change.
While it is technically possible for the Credit Card Processing team to get a head of the game... and it might make them feel more productive... it might be great for their team morale... ask yourself what impact they are having on the rest of the organization. It might not be as positive as you think. So... for all the same reasons you might ask a PO or a BA to slow down writing requirements to fill the product backlog, you might want to ask your Scrum team to slow down building software until the rest of the organization can catch up.
It's counter-intuitive, but if you start thinking past the single team, it might be exactly what you need to do.
6 mai 2010
9 Web CSS Tools You Must Know
Long time no see! :)
Voici un lien intéressant vers des outils CSS en ligne
http://www.queness.com/post/3220/9-web-css-tools-you-must-know
Voici un lien intéressant vers des outils CSS en ligne
http://www.queness.com/post/3220/9-web-css-tools-you-must-know
15 avril 2010
13 simple but useful online tools for web development
http://www.queness.com/post/2959/13-simple-but-useful-online-tools-for-web-development
24 mars 2010
Test-Driven Development
One of the foundational concepts of Agile software development is ensuring that your solution is loosely-coupled, highly-cohesive, and able to respond easily to changes; in this session we will explore the fundamentals of unit testing and their application through the practice of using TDD to evolve the design of your solution such that the results are both testable and flexible in the face of changing real-world requirements.
http://www.testingtv.com/2010/03/24/test-driven-development/
http://www.testingtv.com/2010/03/24/test-driven-development/
22 février 2010
10 Things I Hate About Agile Development!
Agile development. Love it or hate it, there's no doubt that it's here to stay. I've enjoyed a great deal of success thanks to agile software development and agile project management methods, but here are 10 things I hate about Agile!
1. Saying you're doing Agile just cos you're doing daily stand-ups. You're not doing agile. There is so much more to agile practices than this! Yet I'm surprised how often I've heard that story. It really is remarkable.
2. Worrying about the difference between 'Agile' (big A) and 'agile' (small a). You mean you spell it with a big A, omg you're so not cool! The differentiation is between Agile methods and being 'agile', in the true sense of the word. Most people probably don't get the subtlety. When people split hairs about this it gets on my nerves and makes so-called agilists sound like a bunch of overly-religious nerds.
3. Thinking that agile is a silver bullet and will solve all your problems. That's so naiive, of course it won't! Humans and software are a complex mix with any methodology, let alone with an added dose of organisational complexity. Agile development will probably help with many things, but it still requires a great deal of skill and there is no magic button.
4. Claiming to be Agile when you're clearly not 'agile'. Yes, we're doing all the major agile practices, but we're not flexible and we don't seem to understand the underlying agile principles. Were agile in practice but don't demonstrate the values of openness, attention to quality, collaboration, team spirit, etc.
5. People who are anti-agile but with nothing constructive to say about why. I hate that. I've had a few turn up here and enlighten us all with their intellectual comments, such as 'snake oil' or 'agile is a hoax'. Losers!
6. Blaming agile - 'I tried it once and didn't like it'. Projects are difficult. Some projects may even fail, even if you are using agile project management methods. As I said earlier, agile is not a silver bullet. It's important not to blame agile when things go wrong, just as it's important not to claim it's the saviour for all of your ills. Don't blame the process. It's a bit like bad workmen blaming their tools. It's not big and it's not clever!
7. Using agile as an excuse - 'no we can't do that, cos it's not Agile'. 'No I'm sorry, we don't do it that way here'. Following the agile process without fail regardless of the circumstances - even if it's contrary to what the situation really requires for the business or for the customer. If the process is the most important thing, above all else, that's not agile!
8. People who think they're smart enough to adapt agile processes before they've really got enough experience to understand how and *why* it works. It's an easy trap to fall into, but one that should be resisted. Otherwise it's so easy to throw the baby out with the bathwater!
9. People who use agile as an excuse for having no process or producing no documentation. If documents are required or useful, there's no reason why an agile development team shouldn't produce them. Just not all up-front; do it as required to support each feature or iteration. JFDI (Just F'ing Do It) is not agile!
10. People who know more about agile development than me. They're so smug ;-)
Ah, that's better! I feel much better now I've got that off my chest.
Thank you for listening!
Kelly.
P.S. - one more thing! I hate people who rant about agile development on agile blogs. That's just silly.
Picture by beneneuman
1. Saying you're doing Agile just cos you're doing daily stand-ups. You're not doing agile. There is so much more to agile practices than this! Yet I'm surprised how often I've heard that story. It really is remarkable.
2. Worrying about the difference between 'Agile' (big A) and 'agile' (small a). You mean you spell it with a big A, omg you're so not cool! The differentiation is between Agile methods and being 'agile', in the true sense of the word. Most people probably don't get the subtlety. When people split hairs about this it gets on my nerves and makes so-called agilists sound like a bunch of overly-religious nerds.
3. Thinking that agile is a silver bullet and will solve all your problems. That's so naiive, of course it won't! Humans and software are a complex mix with any methodology, let alone with an added dose of organisational complexity. Agile development will probably help with many things, but it still requires a great deal of skill and there is no magic button.
4. Claiming to be Agile when you're clearly not 'agile'. Yes, we're doing all the major agile practices, but we're not flexible and we don't seem to understand the underlying agile principles. Were agile in practice but don't demonstrate the values of openness, attention to quality, collaboration, team spirit, etc.
5. People who are anti-agile but with nothing constructive to say about why. I hate that. I've had a few turn up here and enlighten us all with their intellectual comments, such as 'snake oil' or 'agile is a hoax'. Losers!
6. Blaming agile - 'I tried it once and didn't like it'. Projects are difficult. Some projects may even fail, even if you are using agile project management methods. As I said earlier, agile is not a silver bullet. It's important not to blame agile when things go wrong, just as it's important not to claim it's the saviour for all of your ills. Don't blame the process. It's a bit like bad workmen blaming their tools. It's not big and it's not clever!
7. Using agile as an excuse - 'no we can't do that, cos it's not Agile'. 'No I'm sorry, we don't do it that way here'. Following the agile process without fail regardless of the circumstances - even if it's contrary to what the situation really requires for the business or for the customer. If the process is the most important thing, above all else, that's not agile!
8. People who think they're smart enough to adapt agile processes before they've really got enough experience to understand how and *why* it works. It's an easy trap to fall into, but one that should be resisted. Otherwise it's so easy to throw the baby out with the bathwater!
9. People who use agile as an excuse for having no process or producing no documentation. If documents are required or useful, there's no reason why an agile development team shouldn't produce them. Just not all up-front; do it as required to support each feature or iteration. JFDI (Just F'ing Do It) is not agile!
10. People who know more about agile development than me. They're so smug ;-)
Ah, that's better! I feel much better now I've got that off my chest.
Thank you for listening!
Kelly.
P.S. - one more thing! I hate people who rant about agile development on agile blogs. That's just silly.
Picture by beneneuman
20 février 2010
Agile Game Development : Agile Game Development Checklists
The Agile Game Development Checklists are meant to help drive discussion about the implementation and effectiveness of agile practices (including Scrum, XP, TDD and Kanban) for a team and stakeholders.
This first version contains a checklist for the ScrumMaster role. Revisit how this role adds value to a Scrum Team and how that role can be improved.
read more
This first version contains a checklist for the ScrumMaster role. Revisit how this role adds value to a Scrum Team and how that role can be improved.
read more
12 février 2010
4 février 2010
Shutup.css Silences Web Site Comments [CSS]
While we happen to love comments and the lively discussion that occurs in them, we understand that not everybody wants to see the comments left by other internet users. Shutup.css lets you apply a custom stylesheet and eradicate comments across the web.It's as simple as it sounds. Download the Shutup.css file at the link below and apply it to your custom styles in your web browser. For most browsers you can find custom style sheets under the advanced settings. If you're a Firefox user you can download Stylish to manage styles and give you finer control over which sites the Shutup.css file is applied to—it also makes toggling it on and off easier.
Once you have the style applied to your browser nearly all web sites with comments will no longer be displaying them. The screenshot above shows the end of a Lifehacker article with the style sheet not applied and then applied, removing the comments. Easy but effective.
Have a favorite user style hack? Prefer just to silence YouTube comments? Share it in the comments below.
Shutup.css [via Make]
S'abonner à :
Messages (Atom)
