AGILE IN ACTION

Tag: agile

Wednesday, November 2, 2011

Using Spikes

Posted by Gus Power
The XP practice of 'spiking' has been around for a while but there isn't a whole lot written about it.
Read more...

Monday, December 3, 2007

Standard work is only the best way so far

Posted by Simon Baker
The concoction of Extreme Programming, Scrum and Lean thinking I'm using is the best way I've found to do software product development so far . I'm applying it, I'm inspecting the results, I'm adapting it to continuously improve it, and I'm learning ... all the time. It's Standard Work that is simply a baseline for doing further kaizen . There are other best ways too that relate directly to other peoples' experiences.

Wednesday, September 12, 2007

Weinberg wisdom on agile software development

Posted by Simon Baker
The PM Boulevard has posted 5Qs on Agile with Gerald M. Weinberg . Here are the answers to a couple of questions (the emphasis is my own): 1. Why use Agile methods?
Read more...

Tuesday, September 4, 2007

Managing knowledge plays a part in achieving agility

Posted by Simon Baker
Jack Vinson recently posted 10 tips on Knowledge Management strategies . You should be thinking of these if you want to achieve lasting agility (the strikethroughs and [text] are my editions): Manage the change People before technology [and process] Behavioural change Organisational culture Strategic alignment KM [Agility] in the wild Technology is an enabler [so are tools] Adopt KM [agile and lean] principles Don't stop at the first solution [Intrinsic] motivation

Saturday, July 28, 2007

Time pacing, rhythm and choreography

Posted by Simon Baker
Read more...

Thursday, July 19, 2007

A journey without an end

Posted by Simon Baker
I have a hard time with the words 'adopting Agile' or 'transitioning to Agile'. (Notice that I'm using Agile with a big 'A'.) They suggest an end state, but I don't think there is an end state. It's certainly possible to be 'not agile'. I believe agility is a scale measured by your ability to deliver value to customers in a continuous flow realising maximum return on investment for the business while dealing with change in a rational and empirical way, and having fun doing it . In my mind, achieving agility is simply a journey of continuous inspection and adaptation, and in lean terms, a journey of continuous improvement . It's a journey without an end. And that's no bad thing. Many people are afraid of this "no end-state". Sometimes they use it as an excuse not to embark on the journey. Others simply invent an end-state (and stop trying to improve). I said before that we're not limited by our abilities but by our vision . I see this thinking as a lack of vision. They're not seeing all the step-by-step improvements for what they are: Tangible improvements that add value. If something moves you forward to something better and adds value, it's got to be worth doing for those reasons alone. Who cares about an end-state? As Chris Pitts says , there's no time like the present. So, start your journey today and begin improving from here.

Thursday, May 17, 2007

Iterating user interfaces

Posted by Simon Baker
I like this article about HTML prototyping and agile development . While I wouldn't call it prototyping, it does advocate building the real user interface iteratively, evolving behaviour based on received feedback, and adding functionality incrementally rather than produce a variety of static mock-ups such as wireframes. We've been building user interfaces iteratively. It works best when the creative and Web people are part of the team and are colocated. The benefits include: Tangible progress is visible. A working application is the only true measure of progress. Clients and stakeholders love to see results, even if they're evolving. The sooner you have something real to show off, the happier everyone is going to be. It's more engaging. Because it's tangible people can play with it. Their understanding of how it works improves and they can provide better feedback. It bridges communication gaps. A common vocabulary emerges as people discuss and interact with the prototype, rather than interpret a design document. Communication and feedback are focused and less ambiguous. It's more thorough. It's better to invest a bit more time developing the prototype to gain insight into many variables that are overlooked by wireframes, e.g. state, security, error messages, level of effort, page flow, scripting, etc. It's a reality check. You have to consider factors contributing to the total experience, which you might ignore when creating wireframes, e.g. response time, ease of implementation, cost of maintenance, interfacing challenges, etc. It helps you avoid document debt. You achieve more because you can spend more time with developers evolving a working prototype and receiving valuable feedback, rather than writing and then having to maintain documentation. Talk is cheap. Typically, meetings and design documents are waste. Start writing code immediately. The sooner you uncover issues, the sooner you can understand them and adjust your estimates, and the sooner you can resolve them, avoiding impact to the timeline. To develop user interfaces iteratively using HTML prototyping you need to expect and embrace change. You need to write good code because high quality code is easy to change, and you need to maintain a working interface, always. Start small, and employ varying levels of detail as required. And let things evolve. Being able to change user interfaces quickly gives you an advantage and contibutes to your ability to compete on the basis of speed .
Comments: 1

Wednesday, May 16, 2007

How did it get to be so wrong?

Posted by Simon Baker
A short while ago I said that fixed-price contracts don't work . Over on the Scrum Development group there's a discussion about competitiveness, estimates and organization culture . Dave Martin said: People underbid because it gets them the initial contract as many clients will just go for the lowest bid. Once the project is underway, the costs start to escalate and the client has 2 options - pay up or write the project off and start again. The client is often better off writing off their initial investment and starting over but its amazing how often they don't do that and continue to burn money. Keith Sterling responded: This is why so many large consultancies stick to the waterfall method. By bidding low and stipulating a waterfall approach, yet knowing that 99.99% of all projects will undergo 25-35% change during its lifetime, they know they will be able to make up the shortfall in their bid with high value change requests. It's a well known fact, yet unwritten rule that most large consultancies in the UK base their business model on the volume of change requests they can generate during a project, and why most of these organisations have some of the biggest legal departments I have ever seen. Where is the sense in awarding business based solely on the price? Price is meaningless without a measure of the quality being purchased. If clients award business to the lowest bidder they're likely to receive low quality and high cost. You get what you pay for. And the client-vendor relationship will become acrimonious as neither party is satisified and it falls to the lawyers to fight it out. Deming predicated that driving down the price without regard to quality and service will drive good vendors and good service out of business . He was right but it's actually worse. As Keith describes, we now see companies making money from providing poor quality by charging extortionate sums for change requests. It's part of their business models. What a truly sad state of affairs. Wouldn't it be better to enter into and nurture cooperative partnerships for the long-term that are built on mutual loyalty, trust and confidence, and which share the risks and the rewards? If you treat your partners as extensions to your business and align incentives so that everybody works for the good of the partnership, then quality will return, cost will fall, speed of delivery will increase, customers will be happy and everyone will realise prosperity.

Friday, May 11, 2007

It takes 1 woman 9 months to make a baby

Posted by Simon Baker
But 9 women can't make a baby in 1 month. Despite popular belief, there isn't a direct relationship between coder-headcount and productivity. Developing software is a creative and often complex process. It's not data entry. The other day Gus was asked by a very senior executive why his team of 16 people were far more productive than another team of 150. Both teams work at the same company. The short answer is the larger team is following a waterfall approach in a bureaucratic and political environment, while the smaller team has achieved agility in an organisation enclave. Process has a lot to do with productivity. Ironically many processes, apparently designed to increase productivity, are actually impediments to throughput. They're more concerned with putting ticks in boxes and producing intermediate artefacts than they are about delivering business value with production quality software. Jeremy Miller lists many of the scenarios that slow down a traditional team using waterfall: Waiting for missing requirements. Struggling through ambiguous requirements. Not having timely access to the business people. Delays from sequential hand-offs between disciplines. Testers and developers disagreeing over the interpretation of a requirement. Testers receiving code and not knowing what or how to test the completed software. Having completed code, but not being able to quickly deploy it for testing. Rework because requirements were misunderstood. Slow response time when the business people change their minds. Assumptions about requirements or architecture being overturned. Elaborate documents that quickly become obsolete. Code that was written because it will be needed later ; it never was. The Agile Manifesto values individuals and interactions over processes and tools . You can do away with prescriptive process and achieve significant throughput if you have a disciplined, colocated and cross-functional team (that includes the product owner ), with people who communicate effectively, collaborate intensively and focus on delivering business value. In an environment where they are trusted to self-organise and make decisions, and where they receive feedback continuously, I bet these people will always deliver more than a traditional team ( more a group than a team ) in a command-and-control environment. Why? Because empowerment and ownership breeds responsibility, commitment, accountability and motivation. You'll see delivery, early, often and regularly. Disempowerment and control breeds mediocrity, apathy, fear and demotivation. People turn up but they lack commitment and they don't really take responsibility. You'll see missed deadlines, a distinct lack of delivery, and ultimately you'll smell the dead fish of failure . Skills and practices also affect productivity. Who's more productive? The developer using test-driven development and continuous integration , who checks in code and integrates with others many times a day, and who collaborates with testers performing exploratory testing in parallel. Or the developer who codes for days (if not weeks) before checking in and integrating with others and then hands-off to testers for manual ad-hoc testing, bouncing back and forth as he fixes bugs until the code is working? I bet it's the first developer. Give me an agile process in a lean environment any day.

Sunday, May 6, 2007

Fixed-price contracts don't work

Posted by Simon Baker
When you buy something, you want to know exactly what you'll get and how much it will cost. It makes sense. But this doesn't work when you're buying software development. If only it did. Writing software is a creative process and developing software systems is a complex undertaking. If you think it's possible to identify a single date, somewhere off in the future, upon which you'll receive everything you've requested and for a fixed price, then you're setting yourself up for failure and disappointment. To say how much something will cost, you need to know in great detail exactly what needs to be built so that your estimates for the work can be accurate. But you can't define everything you want, in detail and up front, and get it exactly right so there will be no changes in the future. And no estimate is ever accurate (it wouldn't be an estimate if it was). Let's be honest here. You're unlikely to know exactly what you want because visualisation only goes so far. You'll probably only know what you want when you actually get to play with it. It's only when you experience using a fully functional user interface, with working code beneath it, will you appreciate its usability and decide if it works for you and meets your needs. Now, maybe you can spend an inordinate amount of time eliciting requirements, analysing them and producing a specification, and possibly get close enough to what you really want. But you're still not going to eliminate uncertainty as the project progresses because when people read your specification they'll take away their own interpretation of what you want. If it were my money I'd want to spend it on working software that realises my needs incrementally and helps maintain my competitiveness and not on documentation. A change management process is a good way to ensure your product is built to specification. And your vendor will support this because, since you've beaten him down on price and then fixed it, he'll want to make money on the change requests. This motivates you to cram even more requirements into the specification (even if you don't really need them) just to cover all the options and hopefully minimise any changes down the road and avoid further expense. It rarely works out that way though. Change is still inevitable. A change management process just makes it more difficult to make changes, and consequently you're even less likely to get what you really want. Ironically, the cost of change requests is often responsible for forcing a project over budget. This defeats the purpose of fixing the price in the first place. You can fix dates (although it's not always necessary to do so). And there's always a budget. But when you fix scope too quality inevitably gets compromised. That's bad. Why would you compromise the quality of a corporate asset? You should never compromise on quality. If you acknowledge that you don't know exactly what you want, wouldn't it make more sense to vary the scope? Don't base the contract with your vendor on conformance to a detailed requirements specification. If you do, you're saying all your good ideas happen at the start of a project and you're effectively betting all your money on a hole-in-one. Insist your vendor use an iterative approach to software development so that changes can be accommodated at any time during the project. And have the contract focus on the relationship with the vendor, not on the desired results of the relationship. By that I mean base the contract on incremental delivery of functionality and specify functional goals, not specific functionality. This allows you to evolve the details of the required functionality as the project progresses. Prioritise the functionality by business value and have the vendor work on it in that order. Work continuously with your vendor. Frequently inspect what's been built, provide feedback that steers their effort towards what you really want and and pay per iteration. The Agile Manifesto says: Value customer collaboration over contract negotiation . Enter into and nurture a collaborative partnership with your vendor, which is built around common goals, and shares the risks and rewards. Reference: The consequences of fixed-price IT projects by Scott Ambler.
Comments: 1