Top 2 reads of the year

Posted on Leave a commentPosted in management

1. Wardley Maps

About situational awareness and strategic planning. This includes, why maps matter, how to map, some common economic patterns useful for prediction, common forms of doctrine and the concept of context specific gameplay.

Video: https://vimeo.com/189984496

Slides: http://www.slideshare.net/swardley/an-introduction-to-wardley-maps

2. Boiling frogs

GCHQ’s internal Boiling Frogs research paper on software development and organisational change in the face of disruption – https://github.com/gchq/BoilingFrogs

The pace of disruptive change is increasing, from the rise of cloud technology, social business, the Internet of Things and others. We feel it as much as other government departments and so we offer this internal research paper publicly, not to present policy or guidelines, but to stimulate debate.

So why the title “Boiling Frogs?” The story goes that if a frog is placed in a saucepan of cold water, which is slowly heated, the frog adapts its body temperature to the changing heat of the water and gradually goes to sleep. The frog goes to sleep at 40 ˚C, unaware that at 100 ˚C it will boil! However, if the frog is placed in already boiling water it immediately jumps out to safety.

p.s. other people who made a significant influence – http://agilemindstorm.com/2015/05/12/people-that-made-great-impact-on-my-thinking/

External provider

Posted on Leave a commentPosted in management

When do you use external service provider? I tried following:

  • To provide commodity infrastructure services – in progress, think will work
  • Commercial offerings without mixing in people from your company (defined scope and budget) – failed
  • Fast experiments to validate options (no integration with platform, no involvement of internal people) – success
  • Commercial offerings with heavily involving teams from your company (not fixing scope, but only cooperation period) – success
  • Bringing in industry accepted expert for knowledge sharing, problem solving, review (short-term: up to 2 weeks) – success

Work-to-rule

Posted on Leave a commentPosted in management

When you start defining too many rules. Be aware that people might start working according them!

Work-to-rule is an industrial action in which employees are entitled to do no more than the minimum required by the rules of their contract, and precisely follow all safety or other regulations, which may cause a slowdown or decrease in productivity, as they are no longer working during breaks or during unpaid extended hours and weekends (checking email, for instance).[1][2]Such an action is considered less disruptive than a strike or lockout; and obeying the rules is less susceptible to disciplinary action. Notable examples have included nurses refusing to answer telephones, teachers refusing to work for free at night and during weekends and holidays, and police officers refusing to issue citations. Refusal to work overtime, travel on duty, or sign up to other tasks requiring employee assent are other manifestations of using work-to-rule as industrial action.

APIs are important part of (network) organization

Posted on Leave a commentPosted in management

As network organization is evolutionary and must be constantly adjusted to actual value being delivered you must have evolutionary architecture. Both approaches are aimed to decompose “Big Ball of Mud …”

Even though i think it is essential for network organisation company structured in any way will benefit from this type of product architecture.

You can read more about that in this great article – https://www.thoughtworks.com/insights/blog/microservices-evolutionary-architecture

Microservices meet this definition because of its strong bounded context principle, making the logical division described in Evan’s Domain Driven Design a physical separation. Microservices achieve this separation via advanced DevOps practices like machine provisioning, testing, and automated deployments. Because each service is decoupled from all other services (at the structural level), replacing one microservice with another resembles swapping one Lego brick for another.