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!
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.
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.
For this weekend we'll get some reading on the topic of requirements in Agile:
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.
... 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.
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.
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.