tag:blogger.com,1999:blog-30923301.post7641731087283327157..comments2023-11-05T01:19:06.177-07:00Comments on Curious Mind: What are the three phases of a new project?Mac Nolandhttp://www.blogger.com/profile/07086101163818736928noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-30923301.post-75409540631306195462009-03-02T18:30:00.000-08:002009-03-02T18:30:00.000-08:00good comments. Yes, I was a bit pessimistic that ...good comments. Yes, I was a bit pessimistic that day. Reason being, I'm a realist who looks for simplicity. That is, I look for easy to understand and realistic solutions. And when people spend a year pontificating complicated and un-realistic solutions, I get frustrated when everyone figures out those once great ideas are full of sh*t. <BR/><BR/>Moreover, I'm a believer of flushing out all the sh*t early on so there are no surprises. I hate surprises. I loath surprises. Yet, it seems like dysfunctional projects always have surprises. We've got a few good ones coming. Surprise!Mac Nolandhttps://www.blogger.com/profile/07086101163818736928noreply@blogger.comtag:blogger.com,1999:blog-30923301.post-38670845720487832932009-02-28T09:22:00.000-08:002009-02-28T09:22:00.000-08:00I had this post locked so I could come back to it....I had this post locked so I could come back to it. Were you feeling in a very pessimistic mood? <BR/><BR/>As the manager of some projects that aren't doing so well, I can feel your pain. I spend a bit of my time deflecting anything from other groups, and sometimes even my own, that targets individuals for late releases. Sure, there's bad code. But that bad code would have been caught if we had stuck to original timelines, if we had flushed out all the requirements instead of just the most obvious ones, if we'd been more agile and rolled with the changes instead of demanding we still meet dates set when those requirements weren't known, if we had checked code into dev instead of trying to upstream it w/o knowing the impact, if we had been cheerful in meetings and talked like we had a good project and good people that had met some obvious hiccups instead of gloom and doom about why it wasn't going to meet target, why we introduced risk at half a dozen stages, why we changed our attitude, why we didn't just move requirements to a new stream, why we're worried about FTE overage for developers when we're still holding core team meetings of over a dozen individuals, why we didn't escalate our environment issues so that testing could be done earlier and we could check into lower environments, on and on. In the end, my primary avenue of change is to meet with my group and talk about what we can do differently and then try to influence other groups to see the light of what needs to change, but it definitely takes a village to screw up a project in any appreciable way in my experience (yes, one person can really drop the ball, but usually there are enough eyes and scrums and reviews to see that happening before it's a project killer) and it always feels like that should be common knowledge and embraced as part of the adaptive software development process. Of course, when a project is make or break for your company, the level of concern rises, but if you iteratively tackle the thing in chunks that don't have that deadline feel, everyone seems happier.<BR/><BR/>We have some initiatives we run at that aren't projects per se. I enjoy these immensely because they're like any other product in the vanity phase, but the outcome isn't tied to a product release. Everyone can brainstorm, learn, and if there's a raised feeling of engagement or lessons learned at the end, then there's benefit. Of course, it doesn't pay anyone's salary ;)Scooterhttps://www.blogger.com/profile/07264667176243327560noreply@blogger.com