Project Management
Agile software development, the principles. Principle 8: Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
This is the eight of 12 posts about the principles of agile software development. Purpose is to go back to the start of the agile manifesto (http://agilemanifesto.org/principles.html) and discuss the implementation of the 12 principles in real life software engineering. Goals of agility are to go deliver software of higher quality, faster, with a higher acceptance to end-users and able to follow the changing business requirements to strive for competitive advantage.
The question is: is this going to work in practice or is this only based on a nice marketing and sales story.
Principle 8 : Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely
Sustainable development means constant production of softwarefeatures during a long lasting period. This is done without loss of concentration within the team or a rising amount of errors as a result of fatigue or frustration. Software development is like running a marathon and not 100 meters sprint. You have to keep up to speed but not run so fast that you exhaust yourself or your team members.
I (and many of my colleagues) recall working on More >
On Project Success Factors: Take time for research
In your project, allocate time (and budget!) for research. I used to think that all activities should contribute directly and specifically to the end goal. I now tend more towards the view that you should plan for research. Of course the research should be targeted, but usually a project has a few subjects that will cause you and your team a headache. And generally you can name these areas in advance! Specific problems, let alone solutions, are unclear at the outset. In order to avoid problems down the line it is wise to start your project with research, proofs of concept, name it what you will, to clarify major stumbling blocks.
The most inspiring example of this approach I have been privy to, has been the implementation of Oracle Spatial at a Dutch government agency. A few years back they wanted to consolidate all geographical data from a dozen regional databases to one Oracle Spatial database, covering the Netherlands. This database was needed to allow the introduction of online services to the public. The database had to be completely refreshed every 24 hours, after which the new database would be put online. The most important questions put to this research project were: is More >
On Project Success Factors: Communicate!
A few weeks ago I received a Request for Information for a substantial project. There was one question that struck me: “Describe on which moments your organization communicates with the client organisation.†My first reaction was: when don’t we!
To ensure that you deliver what your client expects, communication is an essential! So, describing when you communicate is easy: whenever it is needed . You need to communicate when: - You have a question you can’t answer. - You make an assumption. - You acquire a new insight. - You got a nagging feeling that something is not right. - …
Communication is not just meant to transfer information. Communication helps foster understanding, commitment and trust.
This all is of course easier said than done. You can increase the chance of effective communication by having a Project Kick-Off with all stakeholders (yes, that’s right, also including the Business Sponsor who does not have the time). Make sure you have regular personal contact on all levels (Director, Manager, Workforce) both formal and informal. And last but not least: give and ask for regular feedback. You never know what you might learn!
On Project Success Factors – Heading straight towards the goal II
“To follow, without halt, one aim: There’s the secret of success.†(Anna Pavlova, a famous ballerina). To repeat the quote from my last blog. The goal must be worth it, of course. What are the benefits, what are the costs. Right…the Business Case. For this you should not hesitate to thing big and look far. The worst thing would be if your Business Case is invalidated in a year.
The first project I managed (from bid to production) was a substantial redesign and refactoring of an existing administrative system for a directorate of a ministry. We won the project, because (as I learned later) we had bid substantially lower than our competitor. They had built the initial system. During the project I soon found out why we had bid lower: I had omitted half the essential work from my estimates. In my defence I must say that this essential work was specified nowhere and could only be fathomed if…you had built the original system!
What also became apparant at the start of the project was that new requirements were emerging from National and European legislation. These requirements were at odds with the system structure: it would be cheaper to do a complete redesign and build a new More >
On Project Success Factors – Heading straight towards the goal I
 “To follow, without halt, one aim: There’s the secret of success.†(Anna Pavlova, a famous ballerina). Completely true of course. A project rarely fails due to one large incident or problem. More often they shift of course imperceptibly, in small steps. Each individual shift is of almost no consequence, the combination is a whole different story.
A few years ago I had the opportunity to experience that again for myself. I was a parttime project manager (“just an additional few hours of work, you knowâ€), we implemented Microsoft Sharepoint (“we are an Oracle and Java company, but this seems to be the best productâ€), we went with the Beta-release (“it has so many features we needâ€), we did not adhere to standard functionality (“adding this is very easy, don’t worryâ€) and we did it iteratively (because we did not know where we were going .
It never ceases to amaze me that everything we do right in our projects for our clients, we instantly forget when doing an internal project. Looking back there were at least five moment where pulling the plug would have been the best possible decision, but…you know: “we have come this farâ€. Our intra- and extranet our More >
Agile software development, the principles. Principle 7: Working software is the primary measure of progress.
This is the seventh of 12 posts about the principles of agile software development. Purpose is to go back to the start of the agile manifesto (http://agilemanifesto.org/principles.html) and discuss the implementation of the 12 principles in real life software engineering. Goals of agility are to go deliver software of higher quality, faster, with a higher acceptance to end-users and able to follow the changing business requirements to strive for competitive advantage.
The question is: is this going to work in practice or is this only based on a nice marketing and sales story.
Principle 7: Working software is the primary measure of progress. How do you measure progress in agile projects? The required functionality is not fixed and the planning of construction and delivery of these requirements is done by the team, in a very late stage. This is something traditional project managers have a hard time to cope with. They think it is impossible to control a project, with an unclear outcome and a planning, that is based upon a work backlog and the duration of a sprint (iteration).
The fundamental measure of progress is measuring things that are finished. Software (in our More >
Recent Comments