I like the idea of Agile and it is a nice way to track progress. What I have been exposed to though is waterfall planning with Agile processes bolted on top. Let's have less meetings with no purpose but let's have a daily standup with little purpose. Let's align teams around vertical feature sets or horizontal end to end solution teams or just random hodgepodge and then have these teams have stand ups where 2/3 of your team is not doing anything related to what you are doing.
How long can that last?
As you can see, I have not seen Agile Nirvana yet but heck, I'd love to try it.
What does this bastardization of Agile result in? Team leads and management trying to squeeze every last drop of developer productivity out of the team by increasing story points (deliverables) by controlling every hour of the Sprint.
How long can that last?
As you can see, I have not seen Agile Nirvana yet but heck, I'd love to try it.
What does this bastardization of Agile result in? Team leads and management trying to squeeze every last drop of developer productivity out of the team by increasing story points (deliverables) by controlling every hour of the Sprint.
For example, we had Slack or research stories. The fact we needed to name these and track them. Is this required?
I think all Devs need time to experiment on non-deliverables. I find the fact that many managers and teams seem to schedule slack with defined deliverables offensive. Some people want to measure everything and are afraid not doing so will take away from the total story points the team could achieve. A Sprint with a low number of points looks bad they think. Rubbish.
In my experience, a Dev that is given slack time with no agenda and no one pressing for burn down rate, completion dates, and other measurements produces tangibles never thought of in planning.
The classic wisdom goes that Devs are lazy. This laziness breads unique solutions to save us time and energy. This laziness and our curiousness means we like to find efficient and new ways to solve things. Bonus.
Can we do something easier? Faster?
Does that mean learning a new language?
Maybe testing out a new dev tool?
Maybe trying out a new process?
Maybe integrating something into our process or product that nobody sees value in until it is there?
Maybe they will read about random APIs. One of these creative explorations might lead to the next breakthrough in efficiency for your product. Perhaps they learned a new API that does most of the heavy lifting for a section of code reducing maintenance and coding costs? As an aside, if your team has been writing a ton of code to solve the same problem more than once then that is a surefire reason to add in slack time so they can refactor that shit.
I'd also like to bring up that Devs are knowledge workers in an environment where managers want to treat them like assembly line workers. I get that a Product needs to ship and to ship you need Devs in the trenches coding. But the flip side is that if you want them to enter the trenches repeatedly then those Devs need time to do mental R&R without burn down rates to track.
I have produced some of my most impactful work as a Dev when I have had slack time. It has let me experiment, look at old processes that took heaps of manual labour and reduce them to automated processes.
I did not do this because someone told me I had 2 days to make some inane thing faster. I did it because, in one case, they gave me 6 weeks to do a task of manually entering bits into memory and then checking the results on the other end of a component. Who wants to do that by hand? Not me. Python driven spreadsheets with test setup, test steps, result collection, and results reporting for the win.
The classic wisdom goes that Devs are lazy. This laziness breads unique solutions to save us time and energy. This laziness and our curiousness means we like to find efficient and new ways to solve things. Bonus.
Can we do something easier? Faster?
Does that mean learning a new language?
Maybe testing out a new dev tool?
Maybe trying out a new process?
Maybe integrating something into our process or product that nobody sees value in until it is there?
Maybe they will read about random APIs. One of these creative explorations might lead to the next breakthrough in efficiency for your product. Perhaps they learned a new API that does most of the heavy lifting for a section of code reducing maintenance and coding costs? As an aside, if your team has been writing a ton of code to solve the same problem more than once then that is a surefire reason to add in slack time so they can refactor that shit.
I'd also like to bring up that Devs are knowledge workers in an environment where managers want to treat them like assembly line workers. I get that a Product needs to ship and to ship you need Devs in the trenches coding. But the flip side is that if you want them to enter the trenches repeatedly then those Devs need time to do mental R&R without burn down rates to track.
I have produced some of my most impactful work as a Dev when I have had slack time. It has let me experiment, look at old processes that took heaps of manual labour and reduce them to automated processes.
I did not do this because someone told me I had 2 days to make some inane thing faster. I did it because, in one case, they gave me 6 weeks to do a task of manually entering bits into memory and then checking the results on the other end of a component. Who wants to do that by hand? Not me. Python driven spreadsheets with test setup, test steps, result collection, and results reporting for the win.
Development is as much creative as technical and giving creative people time to think and experiment can pay dividends. For me personally, my performance reviews have always been about the projects I took on in slack time to make shit better (generally for me and my teammates, which lead to happy managers and better products). Nobody ever rewards me for doing my day job and hitting burn down rates. They reward me for figuring out how to do things faster, better, or cheaper (pick two) when they never thought to ask for that.
These valuable projects come at a cost though. Management, leads, etc, need to give up that time to Devs and let them be creative without measurement.
How much time? I find I need 20% or more in general while I am working on deliverables. After a crunch I like more time so I can recover and experiment with ideas I could not pursue during crunch time.
Remember, this slack time is not going to pay dividends immediately or always. Sometimes a Dev will learn not to use something since it is not the right fit. Or they will try something that ends up being too complex, big, or with not a high enough ROI to be worth continuing. That's ok as well.
We could call these non-productive slack times "mistakes" that we learned from. If this is a problem then I suggest you have people track their slack time with wiki or blog entries. Have them explain what they played with, what the hope was, what the result was, and recommendations for further study.
Don't make the mistake of pegging story points to this and making them track how much work they have done on their slack time. Christ, it isn't slack time if they need to estimate and be accountable that this will result in a deliverable.
Another thing, don't encourage people to have to deliver during slack. If you do they will and they might deliver shit since they have to deliver something. Better to have them say, I tried this, I thought it would help us like this, but it did not work for these reasons. Rather than to have them try to push a new process or tool into the team so as to be producing results.
These valuable projects come at a cost though. Management, leads, etc, need to give up that time to Devs and let them be creative without measurement.
How much time? I find I need 20% or more in general while I am working on deliverables. After a crunch I like more time so I can recover and experiment with ideas I could not pursue during crunch time.
Remember, this slack time is not going to pay dividends immediately or always. Sometimes a Dev will learn not to use something since it is not the right fit. Or they will try something that ends up being too complex, big, or with not a high enough ROI to be worth continuing. That's ok as well.
We could call these non-productive slack times "mistakes" that we learned from. If this is a problem then I suggest you have people track their slack time with wiki or blog entries. Have them explain what they played with, what the hope was, what the result was, and recommendations for further study.
Don't make the mistake of pegging story points to this and making them track how much work they have done on their slack time. Christ, it isn't slack time if they need to estimate and be accountable that this will result in a deliverable.
Another thing, don't encourage people to have to deliver during slack. If you do they will and they might deliver shit since they have to deliver something. Better to have them say, I tried this, I thought it would help us like this, but it did not work for these reasons. Rather than to have them try to push a new process or tool into the team so as to be producing results.
Are you getting slack time? Are you letting your team have slack time? Is everything measured? Does every hour of a Sprint have to have a purpose? Are you over booking employees and under booking creative exploration?
Back off, get some slack time in the schedule with no deliverables, and see if anyone comes up with something you never thought of in the plan.
Here is some more reading about Slack. I might not agree totally with the statements but these should get you thinking about how you can add in slack and see if it produces results for you:
No comments:
Post a Comment