Just Do It - Agile PechaKucha vol.2
Last week I gave a talk about importance of doing what talk about at Agile PechaKucha vol.2 in Kyiv. Here is slidecast from my presentation (in Russian):
Check out the rest of the presentations from that evening. See you on the next event!
Webinar: The Business Driven Software Development
Net Objectives conducts a series of webinars on Business Driven Software Development:
This series provides an introduction on how to achieve Business Agility. Business Agility enables an organization to respond quickly to external forces (such as new market opportunities and competitive forces) as well as to respond quickly to new insights attained internally. While many organizations have achieved the local optimizations of more effective teams, few have achieved agility at the organizational level. Even when team agility has been achieved, if improvements to how the business is selecting their product enhancements isn’t done, overall return on investment of software development may not have significantly improved.
First event is tomorrow at 9 AM PST. Register at the event page to attend the webinar.
SOA Manifesto
Recently I discovered that during 2nd International SOA Symposium they published SOA Manifesto. It follows the spirit of the famous Agile Manifesto, which provoked many discussion and debates over the actual meaning of the statements of that manifesto. (Not) surprisingly there are many other manifestos related to software. Here are some to name a few:
But there is important thing, which puts SOA and Agile manifestos apart from others -- they can not be simply declared by an individual to work. While one can accept, for example, the GNU Manifesto and act as declared and make a difference. With SOA and Agile you can not manifest something individually -- the team has to embrace these ideas together in order to make them work.
I wonder when (and if) we will move to team manifestos instead on manifestos of individuals.
Weekend reading: Requirements in Agile
For this weekend we'll get some reading on the topic of requirements in Agile:
- Writing Good User Stories. Nice concept of INVESTing in user stories.
- Latest description of FDD process. Pay attention to step 2 'Building a Features List'. Apart from precise definition of what a feature is, it introduces an interesting idea of time-boxing for features: a feature should not take more than 2 weeks to implement; if that's not the case - break it down.
- Why I still use use cases. Alistair Cockburn on what can be wrong with user stories.
- Writing Complete User Stories. Nice guide on how to address often perceived problems with user stories.
Weekend reading: Software projects planning and estimation
- Your Will Suffer From Power Laws. There are some things, which are the way the are, and you can not change them, even if you want. You can not spit upwind (at least, not with desirable result); you can not make an apple fall up, when you release it. So with our projects there are some things, which we simply have to learn to live with.
- 10 Deadly Sins of Software Estimation webinar by Steve McConnell. Interesting presentation about art and science of software estimation. A lot of references to statistical studies, which give good food for thought.
- Software estimation considered harmful? Alternative point of view on software estimation as presented by Steve McConnell. DeMarco and Lister refer to study, which suggest highest productivity on projects, which were not estimated at all. Does this mean we should not estimate our projects?
- Evidence Based Scheduling. Practical approach to software estimation developed at Fog Creek.
- Agile Management for Software Engineering: Dealing with Uncertainty. A chapter from great book by David Anderson. Something always goes wrong. The problem is that we do not know what and when, yet we have to plan and execute our projects. This chapter of David's book can help you.
Finally, a tip from Leo Babauta of ZenHabits to a project manager, who needs clear mind, when project is derailed, for finding peace of mind.
Developing software is not enough...
... someone has to be using it. Guys from 37signals got it right:
It feels great to be done with something on the programming side and then feeling free to move on to the next thing. We all do that at times. But it’s not really real until our users are able to enjoy it.
Way too often more attention is paid to the process of creating something than to the actual value of the result for others. The truth is that value is realized not at the moment the product is created and the more so not in the process of creation. Value is realized when the product is delivered and used.
Declaration of Interdependence which is going (hopefully) to drive the way we manage projects puts essential focus on delivery of value:
We increase return on investment by making continuous flow of value our focus
Like quality is everyone's business every day, so delivery of value should be.
Why "agile" is better
Software developers like being "agile", whatever this means. They say being "agile" liberates their creativity and lets positive energies of the Universe flow through them to the code to (hopefully) solve customer's problems. They are committed to using all the practices that e.g. XP suggests, but it generally would be better if somebody else writes unit tests.
For me definition of "agile" changed forever when I first watched David Anderson's interview "Writing Agile Software" and read his book Agile Management for Software Engineering. All the other books on "agile" topics I've come across focus of how freaking cool it is to use agile to develop software, of course, from the point of view of developers. And you are a, hm-m-m, short-sighted conservator if you want developers to do development with, say, RUP.
"Agile" does not equal to "Say no to BDUF and documents". David in his book explains what is agile and why it is better for clients and their businesses.
Jurgen Apello in his blog provides a review for this book, but focuses mostly on the form, not the meaning. True, the book is not fun and makes you think, but it is gratifying when you finally get the clue. Again, this book is not about the fun you get working on agile project, it is about why agile works in business landscape.
Anyway, if you want to better understand the book, my suggestion is to watch the video first.
Project management of future
If you follow advances in agile project management you've heard of Declaration of Interdependence (compare it to Agile Manifesto). This Declaration reflects progress of software development from romantic profession of "ugh, this guy can command a computer" towards pragmatic business and established engineering discipline. We no longer can afford doing technology for pure technology sake. Economics comes into play. Surprising thing to me is that since I first learned about DOI I haven't heard of it at all. Despite of being a well thought out piece of knowledge it did not get referenced too much. Mike Griffiths provides a good analysis why this may be so.
Mike references the Made to Stick book which happens to be on my bookshelf also. Looks like I need to push it up on my reading list.