Planning vs Plan

Posted on Leave a commentPosted in management

We always want to know future especially when it’s related to delivery of complex software projects.context-matters I personally failed in making plans almost always in my career, but improved myself in planning: setting boundaries, watching trends, adjusting often, planning very little ahead, changing direction completely and more…

Also realised that creating too much overhead in formalizing plans and decision making slows you down and reduces motivation in making changes in the plan. We need to change fast and often (at least in certain types of activities) for the following reasons:

  • uncertainty
  • variability
  • imperfect, incomplete knowledge
  • chance
  • chaos
  • volatility
  • disorder
  • entropy
  • time
  • the unknown
  • randomness
  • error
  • variety of outcomes
  • unknowledge
  • simplification of activities
  • optimism

Probably any person who wants to have a very good plan
must have some checklist with things mentioned above which helps to evaluate context. And the more “yes” you have for you context than less formalised plan you should have, adjust it often and shift faster towards network organisation.

Agile and Lean meets IT

Posted on Leave a commentPosted in management, process

Was making presentation about how we were transforming IT into service type instead of control type.

Conclusions

  1. Imagine you have to earn money. Perfectly shifts away your thinking away from “cost efficiency”.
  2. Avoid broad terms. Too much room for interpretation.
  3. Control scope. Be explicit about what you can do. Say “no” to things you can’t.
  4. Monitoring and Transparency. Best way to control things.
  5. De-centralize certain activities. Build for scale.
  6. Grow you process. Evolution vs adoption
  7. Know value flow. Local efficiency is not what you need

[slideshare id=54959255&doc=a1269492-f8d5-4ebc-820e-92b27d1d4599-151110160930-lva1-app6891]

Network Structure: Use verbs to describe your service

Posted on Leave a commentPosted in management

we often focus on results and this drives our behaviour - setting targets and metrics, evaluating performance and etc. But is it always right thing to do? Isn’t action is the thing that describes you service much better?

Couple examples from the top of my head:

  • Zero bugs vs Keep customers happy
    • it’s not only zero bugs that will keep you happy
  • Simple ui workflow vs Help user to do the job faster
    • why to keep it simple?
  • High velocity vs Deliver right things on time
    • working fast and delivering random stuff is not needed
  • Files Storage API vs Will keep your files safe, synced, and easy to share
    • which one would you approach first?
  • Taxi Service vs You’ll get a driver in less than 5 minutes
    • there are lots of taxis now
  • SettingHadoop cluster vs Store and retrieve any data you want
    • the second one just explains it better

Why it’s better and more fun? Because verbs:

  • help you better define what problem you are actually solving. early defined deliverables (names of the service) are not necessarily the right ones and you will have to iterate through couple of versions
  • force you to think how actually you are going to solve the problem
  • describe service better as reflect “why” part
  • help you to differentiate yourself
  • help you to start a conversation with your “client”

And all these are very important for network structure as you need to understand easily who can provide what services to you (including yourself)

Network structure - choose the one you like

Posted on 1 CommentPosted in management

Looking for a way how to organise work in your company? Than i would suggest getting yourself familiar with these works:

  • Organize for Complexity by Niels Pflaeging. http://www.organizeforcomplexity.com 
    • Niels has managed to distill the essential components of organizational development, leadership, and management into a single, short, clear volume that is easy to read and understand
  • Wirearchy by Jon Husband. http://wirearchy.com
    • Organizing principle for interconnected participative era. Implications for biz models, org structures, leadership & mgt. development
  • LiquidO by CocoonProjects. http://liquido.cocoonprojects.com
    • The original “liquid organisation” model for governance, born from direct experience within Cocoon Projects and in use in a growing number of for profit and not-forprofit organisations willing to get liquid.

Inspired by these people i with my team came up with practical implementation of some ideas that we believe will help us to:

  1. Focus on value
  2. Adapt to fast growth
  3. Keep everybody engaged and collaborative
  4. Remain fast and handle bottlenecks