Agile Notes

Responsibility! That seems to be the key issue when moving to an agile mindset. In the beginning I was just confused and frustrated with the resistance. I did not understand how to handle it, nor could I explain why the difference was important and made sense. Now - quite some frustrating moments later - I'm ready to give explaining it a try. Traditionally the Project Manager is responsible for everything. The PM shall develop time plans, scope definitions, milestones, test plans, risk plans - well everything because it is the PM's responsibility! Does this actually mean that the PM spends all his time in the office creating these documents? No - or at least no good PM does. So what happens then? The PM - burdened with the responsibility - goes to the team and asks them to provide the information. Depending on the maturity of the team (and the PM) the PM then has some editorial tasks to compile the information. Then the PM states that the things are done by him because he is r...

Back in the old days it was the Iron Maid that was a tortureres choice. Todays project managers may suffer the same from the Project Iron Triangle. The triangle is accurate in describing the variables that we have to work with i.e. Cost, Time and Scope. Traditionaly the Scope is fixed and then you work with cost and time. Everyone is trying to tie the project to a fixed time and cost too. In Agile the same triangle is present but with a twist. Its easier to say that I want something to this price at this time. Then let the product owner worry about the ROI of that something and let the team togheter with the product owner try to figure out what (scope) maximises RIO under the fixed time and cost.

Customer Impact as Defect Importance The usage of the two defect tracking fields severity and priority is widespread and dominant in defect management circles. But there is a number of problems with these attributes – they allow for ambiguity and they two fields do not focus on what is truly important – customer satisfaction. Let’s face it – without customer satisfaction we are out of business pretty fast. Thus to focus on what is important we have chosen to reflect what is important the defects impact on the customer. But you might say that not all of our systems have a customer! Well think twice – in the case where your systems don’t have an obvious end customer (player/operator/support/…) the component is a part of a producer-consumer chain. Your component allows for some other software module to provide functionality and there you are – you do have a customer! To reflect the impact on the customer we have chosen the following five states: • Catastrophic If this issue isn’t resol...

Never thought that I'd say this but - internal debiting isn't just evil! We have had a situation where money really hasn't been one of the major issues when developing things. Well being that fat has been great - but now things have changed. To the better in some sense. Our product owners has when faced with priority issues always just blamed us for not recruiting fast enough. What I'm wondering is - have we focused on the right things from a business perspective or have we wasted valuable development time on chrome tires? This is where I think that internal debiting actually is a god and not a bad. Everything is useful and tasty when for free! But if you actually have to pay for it - does it carry the same appeal? - probably not! Forcing the stakeholder to provide the cash makes their part so painstakingly much clearer. They only have so much money and they need to get a product developed that will earn back the investment. This implies that they better have to do the...

Just a few days back we fell of the bandwagon and it hurt badly. I'd say our most agile department was forced to close down and put the 10+ games they had into maintenance. Then almost all of the resources was reassigned into core business areas. But nothing bad without some tiny bit of good. In our case it was that we finally got both time and a quite substantial incitement to deal with how we maintain our products and how we run projects also. The product owners has not been accountable for ROI, or it simply hasn't been possible to calculate if a great ROI was better than a huge ROI. From a sound software development standpoint the business has been too successful. But the tide has turned. I finally got everyone accepting that we have to be more restrictive when starting projects. Previously a project has been a pool of resources following every whim of the product owner. But in a competitive world you change the software to earn money . The majority of such changes are eit...