tag:blogger.com,1999:blog-15136575.post1923631146497937316..comments2023-10-17T12:00:16.772+01:00Comments on Code rant: Heisenberg DevelopersMike Hadlowhttp://www.blogger.com/profile/16441901713967254504noreply@blogger.comBlogger86125tag:blogger.com,1999:blog-15136575.post-91378675192554456362019-03-05T10:52:33.886+00:002019-03-05T10:52:33.886+00:00Hi
I've worked in Scrum environments many tim...Hi<br /><br />I've worked in Scrum environments many times. Mostly I would say they are very hit and miss with regarding to predicting task time. Few people actually track time correctly. They don't remove all the non project time from their calculations. Some use a fudge factor to account for lost time. In my experience my scrums which model the dev time correctly have really given the team a feeling for what they can develop in a given set of time and after a few sprints start to get very accurate. Those that don't frequently slip delivery and project feels wobbly and lost in comparison as a days dev time is frequently a half day or less in some environment.<br /><br />You have to model time lost to sprint planning, scrum meetings. holidays, training recruitment etc...<br /><br />Where time is modelled incorrectly I've felt the hole scrum magic to be missing and people come away wondering what it's about and what the benefit is....<br /><br />Some of my best and worst projects have been Scrum based....<br /><br />Anthony<br /><br />Archiehttps://www.blogger.com/profile/09579221074209950475noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-75087736749133080832017-09-08T07:03:33.242+01:002017-09-08T07:03:33.242+01:00keep rocking with useful posts.keep rocking with useful posts.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-15136575.post-16654668843331714962016-09-22T19:00:12.145+01:002016-09-22T19:00:12.145+01:00TRUTH
Been there, done that, got the shirtTRUTH<br />Been there, done that, got the shirtAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-15136575.post-79928376972263795172016-06-22T23:20:15.103+01:002016-06-22T23:20:15.103+01:00I cannot agree more with you! I cannot agree more with you! Anonymoushttps://www.blogger.com/profile/02549071532328748338noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-65035648443468355502016-03-28T03:35:21.377+01:002016-03-28T03:35:21.377+01:00Nailed it. I'm gonna send this link to many a...Nailed it. I'm gonna send this link to many a future managerZhttps://www.blogger.com/profile/00716413049727852782noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-8326038981471782172016-03-22T22:26:24.922+00:002016-03-22T22:26:24.922+00:00Amen, amen! Very well-said. It kills me when manag...Amen, amen! Very well-said. It kills me when management doesn't get this!Sarahhttps://www.blogger.com/profile/15490885898453202287noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-90138410981827404402016-03-08T16:20:24.589+00:002016-03-08T16:20:24.589+00:00Someone may have said this, it is hard to catch up...Someone may have said this, it is hard to catch up on all the comments but let me just boil this down to a core argument outline:<br />Intro<br />1. Describe method one<br />a. Method one made friends happy<br />b. Method one made clients panic<br />c. Method one worked for the beginning but ultimately failed badly (see 1b)<br />2. Describe method two<br />a. Method two made friends sad<br />b. Method two made non-friends happy<br />c. Method two made clients ... unpanicked yet unhappy?<br />d. Method two was not successful (support this)<br />Conclusion (use method one)<br /><br />I'm unconvinced though I started clearly on your side wanting to agree that autonomy provided more productive work than micro management.<br /><br />Both methods failed, for different reasons, few of which have been analyzed and fit none of which convincing solutions have been offered.<br /><br />The issue of who is or is not happy in these methods' environments seems to have no bearing on success. Nor, apparently did the autonomy to whittle away idly on a DSL when the aim had no clarity to the implementors; did the DSL sound like exactly what was requested to the party asking for its needs filled? Considering the response, I'd take it as they absolutely had no idea what you were even trying to do.Lamblinhttps://www.blogger.com/profile/14028133613021082894noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-70453994225712983912016-03-08T13:15:02.179+00:002016-03-08T13:15:02.179+00:00Please ooo i am paid a fortune but dont want to b...Please ooo i am paid a fortune but dont want to be managed , get real.<br /><br />if all developer worked for minimum wage and were then paid for waht was produced only when it was produced. your approach would work.<br /><br />but i garantee no developer would do this.<br /><br />how about i pay you 100k a year and every time there a bug fix or "security fix" you give me half the salry back.<br /><br />how about you pay back the months salary every time you miss a dead line<br /><br />wake up we all live in a real worldAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-15136575.post-1784512449831068192016-02-22T01:22:53.491+00:002016-02-22T01:22:53.491+00:00Great post. I suspect I'll forward it to my bo...Great post. I suspect I'll forward it to my boss the day I resign. <br />It seems to me that there is another huge gap created by this sort of development management.<br />Agile say fix the problem in front of you, but most problems are at heart systemic. The number of times I've fixed a bug with what amounts to a hack because fixing the cause is seen as "beyond the scope of the ticket". <br />I think some version of agile can be useful during bug-fixing periods, or for maybe 2/3 of a large team during the middle of a big build, but (particularly for completely new projects) you need dedicated framework devs who maintain core consistency, refactor to correct issues, and generally just build all the tools the agile devs will rely on.<br />A classic example of this is security. Initially (before release, in the dev environment) security is irrelevant. At some point someone will decide a page needs to be secured, someone will throw together an access security model (totally ignoring data security), and start securing pages.<br />That's not how to do security. Security (if it's relevant) should be the first of the foundations an app is built on. <br />Yes, it means nothing to show at first, yes it takes one of "those" developers to write it, but with it under everything, it ceases to be an issue. Without it, it will always be incomplete.<br />Agile encourages the idea that everything can be broken down into manageable chunks.<br />If a manager is a person that thinks 9 women can have a baby in 1 month, then an agile manager is one who thinks they can allocate a different body part to each woman, and expect a fully assembled baby at the end.Chaos_Crafterhttps://www.blogger.com/profile/09891495284325579374noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-9977151507220891642016-02-21T16:03:09.072+00:002016-02-21T16:03:09.072+00:00To be fair, I work in an environment where scrum d...To be fair, I work in an environment where scrum does actually empower the people who do the work. It requires management, execs, product owners, and scrum masters to all step into the shadows, and that's hard for people to do. Letting the developers make decisions about designing the product and control their own workflow is the goal.Anonymoushttps://www.blogger.com/profile/07527787499290523958noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-19925127146881152072016-02-21T16:00:00.282+00:002016-02-21T16:00:00.282+00:00What went wrong is pseudo scrum; the structure of ...What went wrong is pseudo scrum; the structure of scrum without the principle. It just doesn't work.Anonymoushttps://www.blogger.com/profile/07527787499290523958noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-28338727848353207962016-02-21T11:29:02.863+00:002016-02-21T11:29:02.863+00:00What you describe I call Corporate frAgileĀ©. It ha...What you describe I call Corporate frAgileĀ©. It has process, rituals, and a micromanaging PM 'driving' delivery. It's all a thinly veiled command and control scam wearing supposedly 'transparent' agile clothing. It's one reason I despise Scrum, scrum masters, 'planning poker' and other infantile rituals. The people who thrive in that kind of environment are not creative, experienced or knowledgable.<br />Regarding Jira: in a problem solving, big based, issue based, environment it is useful. It lets you track what has been tried, and what worked, if you use it right. It is not a design tool, it is not really a good scrum tool. It's an operations and maintenance tool, regardless of how people try to use it for everything so they can feel in control.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-15136575.post-27556492849672595262016-02-09T15:53:25.884+00:002016-02-09T15:53:25.884+00:00Read this and see if the downward spiral now looks...Read this and see if the downward spiral now looks eerily familiar: http://www.lindsredding.com/2012/03/11/a-overdue-lesson-in-perspective/Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-15136575.post-50148322726468480222016-02-08T06:28:17.387+00:002016-02-08T06:28:17.387+00:00I think you are missing the point. By forcing the ...I think you are missing the point. By forcing the developers to push spaghetti code via harsh timelines and never allowing for refactoring, they are adding massive development hours and shrinking their margins overall... while also running the risk of losing customers / clients by the amount of bugs introduced. This becomes amplified if you're constantly cycling developers. A company that understands good development processes stands to gain a lot. If the product isn't cash flow positive, but it's being created according to the requirements set forth, it's a problem with the product, not the development team.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-15136575.post-30328049287541129742016-02-08T04:34:42.339+00:002016-02-08T04:34:42.339+00:00This article is incredibly good!!! Thank you Mike ...This article is incredibly good!!! Thank you Mike for writing this.Fernando Pasikhttps://www.blogger.com/profile/06849283681611334345noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-81282031576288844732016-02-07T10:08:36.033+00:002016-02-07T10:08:36.033+00:00Why do you care saving somebody's else ship? A...Why do you care saving somebody's else ship? As mentioned in the comments above - you (me) the developer are just resources and this is in 99% of the time. So why at all bother doing it the right way when you are doing it for somebody who doesn't give an f for you (and this is normal, you don't give an f for them either)? Why take the responsibility? What is your benefit for doing it? Don't get me wrong here. I love software development. I've been programming for more than 20 years (started in 12) read countless books/articles and information of how to grow software and for software craftsmanship. So my point is unless if you are doing it for yourself don't throw too much of your own life into it. I've been trying to persuade tons of PMs and business owners that they just NEED their code refactored and well structured if they want to be able to sustain the product in (the no so far) future. No one listen, and guess what - it is not your money on the line - it's theirs. Project fails you move to the next one (project or employer), you get your paycheck. If you want to do something meaningful - START YOUR OWN company (don't leave your job yet), come up with a product that you LOVE working on (in fact this is no longer called work but fun), let the PM micromanage the project at work, inflate your estimates to the roof, work 2 hours a day for the employer and 10 hours for your own project (your employer is now effectively paying you to build your own project), start selling your product, build some customer base, start selling your product even better, than quit your employer and become an employer yourself (and become a better one).<br /><br />P.S if you're the only one that can understand the code (because you did your best to make huge mess (you've read: How to write unmaintainable code :D ) you'll be the most valuable dev resource in the company :D and guess what the most valuable resource must be paid tons of money ;) and can't be easily replaced by somebody else. You got the point.<br /><br />Cheers, <br />And go work for YOURSELFAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-15136575.post-60938914451549749752016-02-06T17:36:47.344+00:002016-02-06T17:36:47.344+00:00Excellent post..!
Q: ...So how should one manage ...Excellent post..!<br /><br /><b><i>Q: ...So how should one manage developers?</i></b><br /><b><i>A: Self-engaged!</i></b><br /><br />I understand and appreciate the feeling of a need for autonomy after an experience as described above. But I think "autonomous" is the wrong label to send to the management team which is confused about leadership style and lost in the search for methods that deliver signs of progress.<br /><br />I've been following a project from the executive chair, where the manager was not capable of managing the project. The requirements were comprehensive, the PMs knowledge deep, the budget and time sufficient. <br /><br />My guess is that the project failed to meet its goals because the PM didn't engage the developers sufficiently in the system-engineering part. That meant that the dev-teams output lost track of the bigger picture and spend too much time on writing code that got deprecated rapidly. The dev-teams creativity without appreciation of the PMs bigger picture was what produced problems.<br /><br />This became evident when I started to investigate what the product-evolution-tree looked like and asked for the minimum viable product. The PM had failed to communicate this to the dev-team, and the dev-team had failed to stop the PM asking for deliverables prior to understanding the product-evolution-tree.<br /><br />The devs started working on something they didn't understand. That is autonomy without engagement.<br /><br />The PM accepted their autonomy without having ascertained their engagement.<br /><br /><b>The problem was interaction: The process did not leverage on the strength of the individuals</b><br /><br />The solution that we found became stupidly simple: The PM was not allowed to issue a new task on the task list unless he had a user-test for it. If he couldn't come up with a test, he had to sit with the principal software developer until the test or tests where made explicit.<br /><br />To limit the autonomy amongst the devs, their tasks were obviously limited by the tests, but also by architecture as every module had to do one thing and do that one thing well. <br /><br />If they wanted to store data, there was a storage service (a configured db with a client). If they wanted to send messages to other services, they had to use a messaging framework (a resilient queuing system), ..., and if anyone developed anything new it had to have its own generic purpose.<br />This generated the right level of abstract inheritable modules which leveraged on the strengths within the team. Mathematicians came up with clever algorithms. System engineers hardened the interfaces and devOps figured out how to deploy these in a resilient manner. If anyone started on a new "thing", they designed it using the knowledge of all the other team-members, by asking "hey, do we a module that does X?"<br /><br />This self-engaged collaborative approach resulted in new features every 90-360 minutes, which steadily made it into production as the test suite ran non-stop.<br /><br />The point:<br /><br /><b>TL;DR - Autonomy without engagement is just as bad as micro-management.</b><br /><br /><br /><br /><br />Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-15136575.post-82781188727309984762016-02-06T14:36:50.239+00:002016-02-06T14:36:50.239+00:00Thanks for this.
It has inspired me to write my o...Thanks for this.<br /><br />It has inspired me to write my own thoughts based on your post.<br /><br /><br />Why I believe autonomy is so important for individuals, teams and companies.<br /><br />http://davidboyne.co.uk/2016/02/06/automany-is-important.htmlAnonymoushttps://www.blogger.com/profile/11740143633500997096noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-5158651489840198612016-02-06T13:28:00.782+00:002016-02-06T13:28:00.782+00:00The main objective is to produce a good product, a...The main objective is to produce a good product, all effort spent on trying to predict and control how long it will take is effort diverted from actually doing it. The cost of better delivery estimates is later delivery.<br />You can and usually do need to put in a bit of effort towards planning and tracking progress, but the nature of the job makes accurate long term predictions hard, and the point of diminishing returns is quite low. Deathmarch projects often have diverted so much effort into managing the process that they can never make progress at all.Anonymoushttps://www.blogger.com/profile/11229915501728016631noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-73703602345446676302016-02-05T16:42:17.535+00:002016-02-05T16:42:17.535+00:00This comment has been removed by the author.Marcus Popehttps://www.blogger.com/profile/00796388328704563099noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-65760342044652728672016-02-05T06:24:01.211+00:002016-02-05T06:24:01.211+00:00@other anon: "developers deciding on usefulne...@other anon: "developers deciding on usefulness of features" Not deciding, of course not, but a developer is an advisor and has to take this role seriously. I'm speaking as senior and technical lead here, but when a junior sits in a planning, I expect him to think about every story all the same. It's a developer's job to spot bad features, i.e. features that only solve a problem the customer thought he wanted solved. Ask the painful questions that leave the feature crying in the backlog. That's why user stories are so important. You need to tell developers why you want it to give them a chance to do their job. And if you don't, they need to squeeze it out of you.<br /><br />We can all discuss at length what role each "participant" in a software project has, but what it IMHO boils down to in the context of this blog post is: be professional, and if others are not professional in your project, be professional nevertheless.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-15136575.post-46727966011720613842016-02-04T19:55:26.283+00:002016-02-04T19:55:26.283+00:00Ok, I'll get ranted for this, but... developer...Ok, I'll get ranted for this, but... developers deciding on usefulness of features? Sorry, but that's a straight way to get a product being an unsellable bag of cool features. I've been in technical sales for over a dozen of years before recently moving into PM and I've seen several really nice products going off the market because of lack of proper use cases, stories etc. <br />I'm sorry, but I dont see devs doing market research, talking to investors, and doing all strategic business planning related to prod mgmt. Not because they're not capable, but simply because they wouldn't like it (and typically, thanks to their PMs, are not aware of). C'mon, sales and marketing? Show me a Dev being fascinated with it ;) And at the end the product must sell to get us all paid.<br /><br />Business defines problems, devs create solutions. Any of sides getting too much into competencies of the other makes things messy.<br /><br />One more thing - that was already mentioned, but a good pm would redefine "that feature" to free up his team from being stuck there. Taking care of the team is one of duties coming with "manager" in PM title... Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-15136575.post-49421896061233795562016-02-04T14:58:09.669+00:002016-02-04T14:58:09.669+00:00Welcome to the real world of software development....Welcome to the real world of software development. Get used to it.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-15136575.post-90308698995531160672016-02-04T10:14:34.957+00:002016-02-04T10:14:34.957+00:00"Stakeholders" That's the bit that ..."Stakeholders" That's the bit that has to work here. The ticket is not the goal, the working product where your new features are being tested by your customers is where it's at. If your developers can't see the vision of the business they can't contribute (other than to adequately code to someone else's specifications - you need those types too!). You either need the business to better translate the value, or better developers.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-15136575.post-70538449942089806462016-02-04T09:25:01.675+00:002016-02-04T09:25:01.675+00:00Very late reply, but I'm missing something fro...Very late reply, but I'm missing something from this post: don't you see at all where you went wrong?<br /><br />It seems like you already got to the conclusion that a software developer is not an underling who's only waiting for orders. So why did you let others turn you into one? Why did you let a PM make technical decisions for you? Why did you take stories into your sprint that weren't refined enough? Why didn't you break an estimate when you came to the conclusion you needed additional refactoring to cleanly implement it? Why didn't you set a task/story back to TBD when you noticed it didn't make sense?<br /><br />As a software developer you steer the process just as much as the PM does. Non-developers don't understand how your job works, so you can't let them dictate the conditions of your work. At the same time you need to be aware of the conditions of others' work. As soon as you someone as working against you - be it the customer, the PO, the PM whoever - you already lost. That's what it means to be a professional. And sometimes that means you don't shy away from conflict.<br /><br />Yes, all the others didn't work towards the goal and the best of their respective companies, but you didn't either.Anonymousnoreply@blogger.com