Tag Archives: agile

The “science” in the science of …

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.

Good – Cheap – Fast

Good. Cheap, Fast! We all know that only two things can be picked, but always tend to forget that and spend lots of time and effort to have all three.

That is why it’s perfect decoration for a workplace, especially in the meeting rooms where you invite clients. It definitely can work as a reminder of this important truth.


Good Cheap Fast


Network structure – Why? (Part 0)

It was a long journey of trying to understand what organisational structure is best for dynamic growth, experiments, agility and change. While trying to understand how it might work had tons of discussions inside my team and series of disconnected posts validating ideas gathered from various sources about principles and challenges:

But all these were kind of separate notes and most often feedback can summarized into this – “ok, seems reasonable. but what should I do? How my team should act from now on?”

Within our work group we made a decision to write down everything on paper and use it as a starting point for our continuous journey. We call it – POD framework.

Some things to keep in mind. Framework doesn’t describe exact roles with units (product managers, developers, analysts, marketers or whoever is needed) or even how to implement it exactly. Framework sets boundaries and principles how growing organisation must work and what is needed for healthy growth and collaboration.

Will continue sharing main aspects of framework in a series of posts, but you can find a link to whole description at the end of the post. Feel free to comment. So, here we go…


There is a tendency to organize around functions when organisation grows, but POD framework suggests to organize around the consumer forming interdisciplinary product development units. PODs are responsible and autonomous to deliver on metrics indicative of awesome customer experiences.

pods company

The interdisciplinary product development units have members of all skills needed to complete particular tasks, which is obviously a great approach comparing to the component teams. Normally component teams focus only on software development, and leave other parts of product development (pre-development and post-development stages) less attended.

POD shifts focus from software development only. Focus on market and customer needs extend development teams with additional skills needed to deliver value to the identified client (differs from POD to POD  i.e.: feature PODs can have client support <add more if needed> people).

All POD members are focused on meeting market and customer needs (external or internal), and not reaching its own goals that do not always relate to end-user value.

The benefits of it are rapid value delivery due to clear understanding of what and why is valuable and for whom, reduced dependencies, partnership behaviour and increased product quality due to dedicated focus and straightforward communication and feedback. Communication between PODs is based on partnership and value delivery for Company (e.g. Adform).

p.s. Pod framework v 0.2 – https://drive.google.com/open?id=1iHixEsXYKtQB89nFPXiuE6fpFT2sjXs2JpyElCVXie0&authuser=0

Feedback is welcome. Feel free to add comments.

Discipline and Agile

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
  • Improvements
    • Team is seeking for improvements at the end of each iteration. Normally each two weeks!
  • Transparency
    • 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

Before you want to build a feature…

Here is a couple of questions to ask before you want to build a feature.

If we built <feature name>, what measurable business benefit or other positive outcome would be achieved?

If we built <feature>, which roles or user personas would use it, and how often would they use it?

When being a Product Owner what else do you treat as important before you start building something?