We always want to know future especially when it’s related to delivery of complex software projects. 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:
- imperfect, incomplete knowledge
- the unknown
- variety of outcomes
- simplification of activities
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.
Often notice that people tend to be “black and white” when talking about practices in any field, let it be management, design, development or whatever… e.g. go completely scientific and measure everything and be very structured or become completely ad-hoc and reactive.
Of course it’s an option to work in a binary way, but in my opinion it is not necessarily the best way to go while facing complex problem. You must have various “tools” in your toolbox and be creative in applying them depending on a situation or context.
As a confirmation for myself I’ve stumbled upon an article recently which covers exactly the same topic - http://www.jnd.org/dn.mss/the_science_in_the.html
So, can design be a science? Sometimes yes, sometimes no. Can it be empirically based, evidence driven? Yes. Will it have to reply on intuition and the creativity of individual designers? Sometimes, yes.
What manager does? Their main focus is not on people performance and their efficiency, not about rules or KPIs. These are tools that are selected or built with your team. Instead their focus is on value creation, environment and principles.
Want to share ideas how i manage for some reasons:
- it might be helpful to others
- it is extremely curious to me if my point of view is going to be different when i read it later
- learn from others so comments and feedback are welcome
Environment. Results are very important, but we won’t be successful as a team unless each individual is fulfilled.
Style. “Ask. Understand. Change.” Process is only a tool, understanding your business is essential. Go out and talk to people. Adjust to business demand and make changes fast.
- Humor (sometimes even rude) is a big part of the game.
- Direct person. This is my natural behavior. I expect this from my team.
Problem solving. When a challenge is presented, bring along several solutions, one of which does not include spending (more) money. Always try to understand root cause - why, why, why,…
Meetings. Book a meeting only if it can’t be avoided. Prepare, engage invited people, come out with actions.
Professionalism. High internal standards push me to do things in a best way possible. Same is required from team members.
Learning. “Experts” can ruin everything as they are not accepting new information. If you are not changing and learning new things than something is wrong with you.
Change. Processes, tools, structure must always be adjusted to business needs
Winning. My definition of “winning” is that everyone wins: employees, customers, users.
2 seconds improvements are very important but it’s very difficult to see the value in a long-term as such actions are focused on small and early wins.
Visualization has certain power in it. it helps to see things in perspective.
Sticky notes, paper and marker comes to the rescue. Simple visualisation how doing small things helps to big something huge. I guess that’s from where such things come from:
- continuous improvement
- continuous integration
- continuous deployment
- continuous refactoring
- continuous value delivery
Working agile means you need to be more disciplined, not less! Think it’s one of the main reasons why is it so difficult to implement Scrum in a team (not speaking about whole organization). Here are several aspects:
- Estimation and planning
- Iteration planning with clients
- Daily follow-up with a whole team
- Iterative reviews of results and further adjustments
- Team work
- Definition of Done: list of requirements that all team has to contribute to - qa and capacity testing, documentation, presentations, monitoring.
- Time boxes
- Team has to deliver best possible results in a limited time. Requires lot’s of focus and determination
- Team is seeking for improvements at the end of each iteration. Normally each two weeks!
- Results must be presented to clients or main stakeholders at the end of each iteration
p.s. Stumbled upon the same topic in InfoQ - The Importance of Discipline in Agile