Reading time 7 min

Dorien Jorissen

In software development, assumptions can have a serious impact and we should always be on the look-out. In this blog post, we talk about how to deal with assumptions when developing software. Imagine…you’ve been driving to a certain place A place you have been driving to every day for the last 5 years, taking the same route, passing the same abandoned street, where you’ve never seen another car. Gradually you start feeling familiar with this route and you assume that as always you will be the only car on this road. But then at a given moment in time, a car pops up right in front of you… there had been a side street all this time, but you had never noticed it, or maybe forgot all about it. You hit the brakes and fortunately come to a stop just in time. Assumption nearly killed you. Fortunately in our job, the assumptions we make are never as hazardous to our lives as the assumptions we make in traffic. Nevertheless, assumptions can have a serious impact and we should always be on the look-out. Imagine… you create websites Your latest client is looking for a new site for his retirement home because his current site is outdated and not that fancy. So you build a Fancy new website based on the assumption that Fancy means : modern design, social features, dynamic content. The site is not the success he had anticipated … strange … you have build exactly what your client wants. But did you build what the visitors of the site want? The average user is between 50 – 65 years old, looking for a new home for their mom and dad. They are not digital natives and may not feel at home surfing on a fancy, dynamic website filled with twitter feeds and social buttons. All they want is to have a good impression of the retirement home and to get reassurance of the fact that they will take good care of their parents. The more experienced you’ll get, the harder you will have to watch out not to make assumptions and to double-check with your client AND the target audience . Another well known peril of experience is “ the curse of knowledge “. Although it sounds like the next Pirates of the Caribbean sequel, the curse of knowledge is a cognitive bias that overpowers almost everyone with expert knowledge in a specific sector. It means better-informed parties find it extremely difficult to think about problems from the perspective of lesser-informed parties. You might wonder why economists don’t always succeed in making the correct stock-exchange predictions. Everyone with some cash to spare can buy shares. You don’t need to be an expert or even understand about economics. And that’s the major reason why economists are often wrong. Because they have expert knowledge, they can’t see past this expertise and have trouble imagining how lesser informed people will react to changes in the market. The same goes for IT. That’s why we always have to keep an eye out, we don’t stop putting ourselves in the shoes of our clients. Gaining insight in their experience and point of view is key in creating the perfect solution for the end user. So how do we tackle assumptions …? I would like to say “Simple” and give you a wonderful oneliner … but as usual … simple is never the correct answer. To manage the urge to switch to auto-pilot and let the Curse of Knowledge kick in, we’ve developed a methodology based on several Agile principles which forces us to involve our end user in every phase of the project, starting when our clients are thinking about a project, but haven’t defined the solution yet. And ending … well actually never. The end user will gain new insights, working with your solution, which may lead to new improvements. In the waterfall methodology at the start of a project an analysis is made upfront by a business analist. Sometimes the user is involved of this upfront analysis, but this is not always the case. Then a conclave of developers create something in solitude and after the white smoke … user acceptance testing (UAT) starts. It must be painful for them to realise after these tests that the product they carefully crafted isn’t the solution the users expected it to be. It’s too late to make vigorous changes without needing much more time and budget. An Agile project methodology will take you a long way. By releasing testable versions every 2 to 3 weeks, users can gradually test functionality and give their feedback during development of the project. This approach will incorporate the user’s insights, gained throughout the project and will guarantee a better match between the needs of the user and the solution you create for their needs. Agile practitioners are advocating ‘continuous deployment’; a practice where newly developed features will be deployed immediately to a production environment instead of in batches every 2 to 3 weeks. This enables us to validate the system (and in essence its assumptions) in the wild, gain valuable feedback from real users, and run targeted experiments to validate which approach works best. Combining our methodology with constant user involvement will make sure you eliminate the worst assumption in IT: we know how the employees do their job and what they need … the peril of experience! Do we always eliminate assumptions? Let me make it a little more complicated: Again… imagine: you’ve been going to the same supermarket for the last 10 years, it’s pretty safe to assume that the cereal is still in the same aisle, even on the same shelf as yesterday. If you would stop assuming where the cereal is … this means you would lose a huge amount of time, browsing through the whole store. Not just once, but over and over again. The same goes for our job. If we would do our job without relying on our experience, we would not be able to make estimations about budget and time. Every estimation is based upon assumptions. The more experienced you are, the more accurate these assumptions will become. But do they lead to good and reliable estimations? Not necessarily… Back to my driving metaphor … We take the same road to work every day. Based upon experience I can estimate it will take me 30 minutes to drive to work. But what if they’ve announced traffic jams on the radio and I haven’t heard the announcement… my estimation will not have been correct. At ACA Group, we use a set of key practices while estimating. First of all, it is a team sport. We never make estimations on our own, and although estimating is serious business, we do it while playing a game: Planning poker. Let me enlighten you; planning poker is based upon the principle that we are better at estimating in group. So we read the story (chunk of functionality) out loud, everybody takes a card (which represent an indication of complexity) and puts them face down on the table. When everybody has chosen a card, they are all flipped at once. If there are different number shown, a discussion starts on the why and how. Assumptions, that form the basis for one’s estimate surface and are discussed and validated. Another estimation round follows, and the process continues till consensus is reached. The end result; a better estimate and a thorough understanding of the assumptions surrounding the estimate. These explicit assumptions are there to be validated by our stakeholders; a great first tool to validate our understanding of the scope.So do we always eliminate assumptions? Well, that would be almost impossible, but making assumptions explicit eliminates a lot of waste. Want to know more about this Agile Estimation? Check out this book by Mike Cohn . Hey! This is a contradiction… So what about these assumptions? Should we try to avoid them? Or should we rely on them? If you assume you know everything … you will never again experience astonishment. As Aristotle already said : “It was their wonder, astonishment, that first led men to philosophize”. Well, a process that validates the assumptions made through well conducted experiments and rapid feedback has proven to yield great results. So in essence, managing your assumptions well, will produce wonderful things. Be aware though that the Curse of Knowledge is lurking around the corner waiting for an unguarded moment to take over. Interested in joining our team? Interested in meeting one of our team members? Interested in joining our team? We are always looking for new motivated professionals to join the ACA team! {% module_block module "widget_3ad3ade5-e860-4db4-8d00-d7df4f7343a4" %}{% module_attribute "buttons" is_json="true" %}{% raw %}[{"appearance":{"link_color":"light","primary_color":"primary","secondary_color":"primary","tertiary_color":"light","tertiary_icon_accent_color":"dark","tertiary_text_color":"dark","variant":"primary"},"content":{"arrow":"right","icon":{"alt":null,"height":null,"loading":"disabled","size_type":null,"src":"","width":null},"tertiary_icon":{"alt":null,"height":null,"loading":"disabled","size_type":null,"src":"","width":null},"text":"View career opportunities"},"target":{"link":{"no_follow":false,"open_in_new_tab":false,"rel":"","sponsored":false,"url":{"content_id":229022099665,"href":"https://25145356.hs-sites-eu1.com/en/jobs","href_with_scheme":null,"type":"CONTENT"},"user_generated_content":false}},"type":"normal"}]{% endraw %}{% end_module_attribute %}{% module_attribute "child_css" is_json="true" %}{% raw %}{}{% endraw %}{% end_module_attribute %}{% module_attribute "css" is_json="true" %}{% raw %}{}{% endraw %}{% end_module_attribute %}{% module_attribute "definition_id" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "field_types" is_json="true" %}{% raw %}{"buttons":"group","styles":"group"}{% endraw %}{% end_module_attribute %}{% module_attribute "isJsModule" is_json="true" %}{% raw %}true{% endraw %}{% end_module_attribute %}{% module_attribute "label" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "module_id" is_json="true" %}{% raw %}201493994716{% endraw %}{% end_module_attribute %}{% module_attribute "path" is_json="true" %}{% raw %}"@projects/aca-group-project/aca-group-app/components/modules/ButtonGroup"{% endraw %}{% end_module_attribute %}{% module_attribute "schema_version" is_json="true" %}{% raw %}2{% endraw %}{% end_module_attribute %}{% module_attribute "smart_objects" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "smart_type" is_json="true" %}{% raw %}"NOT_SMART"{% endraw %}{% end_module_attribute %}{% module_attribute "tag" is_json="true" %}{% raw %}"module"{% endraw %}{% end_module_attribute %}{% module_attribute "type" is_json="true" %}{% raw %}"module"{% endraw %}{% end_module_attribute %}{% module_attribute "wrap_field_tag" is_json="true" %}{% raw %}"div"{% endraw %}{% end_module_attribute %}{% end_module_block %}

Reading time 4 min

Dorien Jorissen

ACA does a lot of projects. In the last quarter of 2017, we did a rather small project for a customer in the financial industry. The deadline for the project was at the end of November and our customer was getting anxious near the end of September. We were confident we could pull off the job on time though and decided to try out an experiment. We got the team together in one room and started mob programming . Mob what? We had read an article that explains the concept of mob programming. In short, mob programming means that the entire team sits together in one room and works on one user story at a time. One person is the ‘driver’ and does the coding for a set amount of time. When that time has passed, the keyboard switches to another team member. We tried the experiment with the following set-up: Our team was relatively small and only had 4 team members. Since the project we were working on was relatively small, we could only assing 4 people. The user stories handled were only a part of the project. Because this was en experiment, we did not want the project - as small as it was - to be mobbed completely. Hence, we chose one specific epic and implemented those user stories in the mob. We did not work on the same computer. We each had a separate laptop and checked in our code to a central versioning system instead of switching the keyboard. This wasn't really a choice we made, just something that happened. We switched every 20 minutes. The article we referred to talks about 12, but we thought that would be too short and decided to go with 20 minutes instead. Ready, set, go! We spent more than a week inside a meeting room where we could, in turn, connect our laptops to one big screen. The first day of the experiment, we designed. We stood at the whiteboard for hours deciding on the architecture of the component we were going to build. On the same day, our mob started implementing the first story. We really took off! We flew through the user story, calling out to our customer proxy when some requirements were not clear. Near the end of the day, we were exhausted. Our experiment had only just started and it was already so intense. The next days, we continued implementing the user stories. In less than a week, we had working software that we could show to our customer. While it wasn’t perfect yet and didn’t cover all requirements, our software was able to conduct a full, happy path flow after merely 3 days. Two days later, we implemented enhancements and exception cases discussed through other user stories. Only one week had passed since our customer started getting anxious and we had implemented so much we could show him already. Finishing touches Near the end of the project, we only needed to take care of some technicalities. One of those was making our newly-built software environment agnostic. If we would have finished this user story with pair programming, one pair would know all the technical details of the software. With mob programming, we did not need to showcase it to the rest of the team. The team already knew. Because we switched laptops instead of keyboards, everyone had done the setup on their own machine. Everyone knew the commands and the configuration. It was knowledge sharing at its best! Other technicalities included configuring our software correctly. This proved to be a boring task for most of the navigators. At this point, we decided the mob experiment had gone far enough. We felt that we were not supposed to do tasks like these with 4 people at the same time. At least, that’s our opinion. Right before the mob disbanded, we planned an evaluation meeting. We were excited and wanted to do this again, maybe even at a bigger scale. Our experience with mob programming The outcome of our experiment was very positive. We experienced knowledge sharing at different levels. Everyone involved knew the complete functionality of the application and we all knew the details of the implementation. We were able to quickly integrate a new team member when necessary, while still working at a steady velocity. We already mentioned that we were very excited before, during and after the experiment. This had a positive impact on our team spirit. We were all more engaged to fulfill the project. The downside was that we experienced mob programming as more exhausting. We felt worn out after a day of being together, albeit in a good way! Next steps Other colleagues noticed us in our meeting room programming on one big screen. Conversations about the experiment started. Our excitement was contagious: people were immediately interested. We started talking about doing more experiments. Maybe we could do mob programming in different teams on different projects. And so it begins… Have you ever tried mob programming? Or are you eager to try? Let’s exchange tips or tricks! We’ll be happy to hear from you!

Reading time 10 min

Dorien Jorissen

Suppose you’re a Product Owner in an Agile delivery team, ready to get working on your product. In order to do that, you’ll need to give your development team a goal and a list of things to work on. If you use SCRUM as the framework, you’d call that list of things to work on a Product Backlog . From the SCRUM guide: The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. Product Backlog items have the attributes of a description, order, estimate, and value. Product Backlog items often include test descriptions that will prove its completeness when “Done”. Okay, so you need to start with a backlog, prioritize as you see fit and then build the highest priority items first. SCRUM – and Agile development in general – is both incremental and iterative (see here or here for a good explanation of those terms). Let’s illustrate this with an example. When a customer orders a car – and we use SCRUM to implement it – we might iterate on the chassis and incrementally build the car, like this: However, as a Product Owner ( the role you take as a Product Manager), you’re left with a few questions: Where does the backlog come from? How can I be sure that it solves a need of the end user? How can I be sure that the development team will actually deliver my interpretation of the requirement? How can I be sure that I adapt to changes and still give my architect a clear (less evolving) set of parameters to work on? In this blog post, we’ll try to gradually answer those questions. Focus on the customer's underlying need Let’s start with the second question on our list: how can I be sure that it solves a need of the end user? Henrik Kniberg correctly points out: We start with the same context – the customer ordered a car. But this time we don’t just build a car. Instead we focus on the underlying need the customer wants fulfilled . Turns out that his underlying need is “I need to get from A to B faster”, and a car is just one possible solution to that. Compared to our previous example of a customer ordering a car, it would now look like this: Said plainly, this means that you first need to unravel the real problem and adapt as you see fit . The unraveling of the problem is iterative in nature: as long as you don’t get confirmation that you’re solving a real need, you need to change and adapt. You present the end user with a best guess of what a solution might look like. As long the user is not satisfied, you have to dig deeper and come up with alternatives. Ultimately, you hit the sweet spot and get confirmation that you understood the problem. This confirmation can be based on real usage data, qualitative insights or a combination of both. SCRUM doesn’t indicate how you should implement Henrik’s idea. My understanding is that there is a preference for developing software and focusing the sprint on ending with an increment . This means working software is used as an artefact during the iteration towards defining the problem. The drawback, however, is that the team needs to re-work already implemented increments, as they need to adapt to new insights. I checked the software development wastes and identified the potential ones: Estimation not possible due to poor analysis/information gathering (Partially Done Work). Technical complexity not analyzed properly (Partially Done Work), because it doesn’t make sense to do so during an iteration. Wrong choice of technology or solution (Defects), because the non-functional requirements are a moving target. Redesigning due to missed requirements (Defects). These are still concerns to be addressed which can be solved by a proper product discovery step . Let’s first revisit the questions a Product Owner might be left with and indicate which ones we’ve solved: Where does this backlog come from? How can I be sure that it solves a need of the end user? ✅ We start with an idea and iterate until we find a solution that fulfills a need. We keep doing this until we get a confirmation. How can I be sure that the development team will actually deliver my interpretation of the requirement? How can I be sure that I adapt to changes and still give my architect a clear (less evolving) set of parameters to work on? ❌ This makes the problem bigger: the development team now needs to do (at least some) more rework to cover up all the changes. Discover your user's needs In order to eliminate the potential wastes with Henrik’s example, you need to split the iterative part (finding out what the user needs) and the building of the software (crafting a solution for the problem). Finding out what the user needs implies a so-called discovery step . Marty Cagan , the “most influential person in the product space”, agrees : In Henrik’s example, the team is working to simultaneously determine the right product to build, and at the same time to build that product. And they have one main tool at their disposal to do that: the engineers. So what you see is a progressively developed product, with an important emphasis on getting something we can test on real users at each iteration. Henrik is emphasizing that they are building to learn, but they are doing this with the only tool they think they have: engineers writing code. If you read carefully, Henrik does mention that the engineers don’t actually need to be building products – they could be building prototypes, but with most teams I meet, this point is lost on them because they don’t understand that there are many forms of prototypes , most of which are not meant to be created by engineers. That’s right: writing software might be a good solution to find out what the user wants, but more often than not, it is the most expensive way to get there. With a discovery step, you can focus on the objectives of a product: is it valuable, usable, feasible and viable? This step is mostly iterative. The end result is a clear definition of the problem and hence a possible solution to that problem; one that has a high probability of solving a user’s need. Because you took a discovery step, this means you can describe the real problem to the engineering team. You can also describe the problem in more detail and also describe what kind of properties you expect from the end solution, e.g. a fitness function which places the solution in context. The development teams then figures out how to build that solution. This is the delivery step and it is mostly incremental. Product discovery track versus delivery track With the product discovery and delivery steps, there are two tracks the team must consider: a product discovery track and a delivery track . Let’s revisit the Product Owner’s questions a third time and indicate which ones we’ve solved: Where does this backlog come from? How can I be sure that it solves a need of the end user? ✅ ✅ We start with and idea and iterate until we found a solution that fulfills a need. We should really spend more time with our end users to really understand their problem. We should try to do this as fast as possible so that the engineering time doesn’t run out of work. How can I be sure that the development team will actually deliver my interpretation of the requirement? In terms of problem description, I’m able to provide more detail and give more context. How can I be sure that I adapt to changes and still give my architect a clear (less evolving) set of parameters to work on? The engineers really know it’s going to be a car before they can come up with a suitable architecture up to the task, and they may in fact choose to implement this architecture with a different delivery strategy than one designed to learn fast. As the risks are tackled in discovery and the necessary delivery work becomes clear, that delivery work progresses much faster than it would otherwise. Dual Track: product discovery and delivery happen simultaneously Discovery work focuses on fast learning and validation. But how do you chain that together with delivery work? When a project starts , you might do discovery first and then – somewhat later – let the engineering team start. It becomes like this : That looks a lot like Waterfall ! But it doesn’t have to be like this. Jeff Patton , a veteran Product Manager and writer of the book User Story Mapping , says it is all happening at once (Dual Track). Instead of a waterfall, we get a loop. A discovery learning loop looks a bit like this: It starts by describing what we believe is the problem we’re trying to solve and for whom, the solution to solve the problem, and how we’d measure its success. Product discovery loops chain together like this: Discovery work uses irregular cycle lengths. It’s ‘lean’ in the sense that we’re trying to make the discovery cycle as short as possible. Ideas in discovery mutate and very often get abandoned, which is the best move forward into more deliberate development cycles. Takeaway In order to eliminate potential risks, you need to be aware of both the discovery and delivery steps . The discovery step focuses on the objectives of a product: value, usability, feasibility and viability and is mostly iterative. The delivery step focuses on how to build a product and is mostly incremental. While the steps are separate, the tracks happen at the same time, which we call Dual Track. Jeff Patton’s article on Dual Track also mentions a few important points. These two tracks are two types of work performed by the same team. Discovery must check regularly with the team on feasibility, correct implementation and technical constraints that affect design decision. Delivery uses insights from discovery during development. Discovery focuses on the riskiest assumptions first, i.e. user problems of which we have low confidence they solve a real user need (or the need is unknown). Delivery focuses on solutions for which we have high confidence that it solves a user’s problem. The confidence might come from validated learning during discovery. Or we start – e.g. in the beginning of a cycle – with backlog items for which we think no discovery is needed, such as technical work or features of which we already have high confidence they solve a user problem. The two tracks are done in parallel : Discovery / Iteration : focus on the riskiest assumptions (problems of which we have the least knowledge of) and try to define them with the least effort possible. Delivery / Increment : focus on a well-defined solution (we have high confidence the end user needs it) and tackle the ones with highest value first. The tracks don’t stop as soon as you’ve discovered one problem to fix. The next problem is already looking around the corner. In our example with the customer ordering a car (“I need to get from A to B faster”), we might also think the user needs shelter, which can range from a simple hut to a castle. A final remark: this blog post started with SCRUM as the delivery framework, but the method ology doesn’t really matter: it could be Kanban, Crystal XP and even Waterfall as long as the team is able to keep pace in the two tracks. But of course, since the discovery part focuses on learning fast , an Agile methodology suits better. Left-over questions Let’s revisit the Product Owner’s questions one last time and indicate which ones are solved now. Where does this backlog come from? ✅ The backlog comes from assumptions which are validated during discovery. However, there is a new question: how do we identify the list of assumptions to focus on? Where does the list of Opportunities come from? ❓ How can I be sure that it solves a need of the end user? ✅✅✅ We start with an idea and iterate until we found a solution that fulfills a need. I should really spend more time with my end users and really really understand their problem. I should try to make this as fast as possible, so that the engineering time does not run out of work. Do this in parallel, with the whole team. How can I be sure that the development team will actually deliver my interpretation of the requirement? ✅ In terms of problem description, I can give more detail and give more context. Involve (at least part) of your engineering team in discovery. This way, they get in touch with the real end user get a better understanding of the user’s real world. How can I be sure that I adapt to changes and still give my architect a clear (less evolving) set of parameters to work on? ✅ The engineers really know it’s going to be a car before they can come up with a suitable architecture up to the task. They may in fact choose to implement this architecture with a different delivery strategy than one designed to learn fast. The risks are tackled in discovery and the necessary delivery work becomes clear. The delivery work can now progress much faster than it would otherwise

Reading time 4 min

Dorien Jorissen

Estimating the effort necessary to develop certain functionalities when writing software gives your customers some certainty and predictability. That being said: making software development estimates is usually not the most popular part of a developer’s job. However, we’ve found a way to gamify development estimates and make them a lot more fun, without sacrificing accuracy. In this blog post, we’ll teach you how to make software development estimates fun with rockstar planning poker. Making estimates for predictability Whenever a feature is clearly defined, it gets split up into user stories . Here’s an example of such a user story: “As a user of this service, I want to invite my friends so that we might enjoy the service together.” Before we start the development of any user story, we estimate the effort we think it’ll take. This way, we’re able to estimate its complexity in a fairly detailed manner and give our customers a certain level of predictability in advance. To be able to do so, we measure how many days it takes us to complete one story point . Story points are a unit of measure for expressing an estimate of the overall effort that’s required to fully implement a user story. The effort is the average number of days one team member needs to complete a story point over a certain time period. The effort multiplied with our team’s capacity gives us an idea of the team’s story throughput , the amount of story points a team can develop over a given period of time. If you extrapolate the story throughput, you can get a clear predictability of the scope you can realize with a team over time. At this stage in the development process, we don’t quite know the intricate details of a user story yet. However, we’ve already done our ‘homework’ and know enough to accurately estimate the complexity of the development of the user story. Estimating with planning poker Planning poker is an ideal way to get to detailed estimates. This way of estimating was described by Mike Cohn in his book Agile Estimating and Planning . During a planning poker session, a user story is estimated by the team that will be working on it. First, the product manager explains what we want to achieve with the user story. Then, the team discusses about what exactly needs to be done to get there, until they reach a consensus about the story. After that, every team member uses ‘planning cards’ to individually estimate the effort required to complete the story. At the count of three, every team member simultaneously turns around their planning card to reveal their estimation in story points. If there are any major differences, the team continues to discuss the story’s complexity until a new consensus is reached. At ACA, we use a series of custom cards to denote a story’s complexity in story points. We have cards with the numbers 0.5 – 1 – 1.5 – 2.5 and 4. However, over time we’ve noticed that stories estimated to be 2.5 or 4 story points introduce more workload and uncertainty, which in turn comprises the predictability towards the customer. Now, all stories that are estimated to be more than 1.5 story points are split up into smaller parts. We’ve therefore limited the numbers on our cards to just 0.5 – 1 and 1.5. So what about rockstar planning poker? Most technical people aren’t very fond of making estimates. Estimation session are tiring and demand a lot of energy, even when using planning poker to gamify the planning process. To liven up those sessions, we’ve been using something we call rockstar planning poker for a few years now. Instead of using cards to denote a story points, we use our hands. Just like in ‘rock, paper, scissors’, we all count to three and then all show our hands to make one of the following signs. Pinkie The universal rockstar signal to order a beer, especially in the lovely student town of Leuven in Belgium. This signal denotes 0.5 story points. Index finger The rockstar way of saying hello! This signal denotes 1 story point. Little finger and index finger The universal way of letting everyone know to rock on. Used to denote a complexity of 1.5 story points. Middle finger The universal signal for … This signal is used to say that the user story needs further clarification or splitting up in smaller parts. Takeaway Rockstar planning poker is an ideal way to keep things fun, and keeping things fun ensures more involvement and work of a high quality. Rockstar planning poker doesn’t necessarily yield better results when it comes to estimating effort, but it has livened up our teams’ estimation sessions. All you need is your hands! So, if you’re tired of those exhausting estimation sessions, why not try rockstar planning poker to spice it up a bit? Good luck, have fun and let us know how you did!

Reading time 7 min

Dorien Jorissen

An anthology of painful truths (and how to cope) Rookie mistakes As with many Product Managers I know, the job was handed to me like a hot potato on a burning silver platter. By lack of other volunteers. By accident. And with little context. Moreover, I had just rolled into the tech world at the time. So obviously, I had no leads on what to think, feel and do. And then I stumbled upon Horowitz’ Good Product Manager/Bad Product Manager article. The infamous CEO phrase, " a good product manager is the CEO of the product" immediately got to me. I vividly remember a sudden feeling of pride and empowerment rushing through my veins when I read it… I was going to change the world! If I could meet “past” me now, I’d slap her in the face. Because it wasn’t long before I started to struggle with empowerment, responsibility, authority and decision making (or the lack thereof). And thus came the inevitable black day when I found out that… well, Product Managers are not the CEO of anything . I felt awfully forlorn when this hit me. Lied to. At loss. How was I supposed to change the world when I didn’t have the mandate to actually do so? This just in: it’s not easy and there’s not one answer. At all. I learned there will just always be days when you’ll seem to be shovelling a big pile of p00p from left to right. But there will always be a silver lining too. I’ve put together a list of painful realities about empowerment in Product Management that unraveled before my weary eyes. To soften the blow, I’ve injected some silver rays of hope. Just to make sure you’re not commuting home in tears with your resignation letter in your hands after you read this. The house always wins As a Product Manager you spend all of your time working on Very Important Stuff. Talking to customers, exploring and validating brilliant (or not so brilliant) new ideas, crunching numbers of analysis reports, trying to translate what the development guys are telling you, etc… All this knowledge you gather on a daily basis puts you in the perfect position to advise the decision-makers in the building. And luckily, people acknowledge this. Therefore they invite you at the decision-making table to present your esteemed recommendations. So when the invite comes in, you go and pour your heart and soul into crafting an inspiring and convincing exposé. You work for days and nights and then some. Until finally the day comes when you get to showcase this masterpiece. You seize the moment. You speak with fiery passion. You ooze pride, confidence and vision and you paint compelling pictures. And when you’re done everyone looks at you like you’re see-through. Uncomfortable silence fills the room. After a few awkward questions and dito answers the meeting goes on. At the end of it, the C*O, VP Ninja and Something Director all agree. We’re going to do exactly the opposite of what you just presented. High fives are given, fists are bumped, great meeting everyone! Let’s go get ‘em. What on earth just happened? When I first experienced this kind of folly, I thought it was me. I’m a rather petite woman. I also don’t wear pencil skirts or two-piece suits. Heck, a customer once even asked me to serve him coffee at an event where I was going to be presenting the product’s strategy because he thought I was the waitress. So obviously the first thing I did was question myself. Guess what? It wasn’t me. And it isn’t you. It’s the system, stupid. No matter how hard we work on getting the facts straight; no matter how well we empathise with our stakeholders and show instead of tell… at the end of the day, it’s out of our hands. The house always wins. Some days we’ll land exactly where we wanted to and others we’ll have to suck it up and get in line. Don’t worry though. We can (and should ceaselessly strive to) change the system from within. Just keep reading. “He knows nothing; and he thinks he knows everything. That points clearly to a political career.” George B. Shaw really nailed it with this quote. It took a while for me to admit, but it actually relates quite well to Product Managers. One of the definitions of Product Management, as spelled out by Martin Eriksson, is “the intersection between the functions business, technology and user experience”. A.k.a the Venn diagram we’ve all once used to explain what we do. This diagram is not telling you we are experts in all those functions. It’s telling you we deeply care about each of them. That we surround ourselves with experts in the fields we are less experienced in. And that we don’t know about all the details, but we do see the overall picture. So… Do we know everything? If we take it literally, we don’t. But speaking for myself: I sure like to think that I do, because I get the bigger picture…You got me there, G. And then the politics. Oh, the politics. I personally loathe company politics. It drives me nuts. It’s bonkers. Overhead and just plain noise if you ask me. But love it or hate it, it’s the way the world goes round. While I’ve always tried to tell myself I steer away from it, I just have to admit it woud not help my career if I actually did. As we found out earlier, us Product Managers have very little authority. Consequently we have to rely on others to make the decisions we want them to make. So we really have no choice but to dive knee-deep in the office politics. We can’t ever overlook or bypass people. Not even if we think they’re incompetent wankers. We have to play the game and work the folks in both the formal and informal organisation charts. This all implies that — whether we like it or not —Product Managers are politicians in many ways. Diplomats. Tacticians. Mediators. For me this was a bitter pill to swallow. Because let’s be real: no one likes politicians. Politics (especially the office kind) are exhausting. There’s nothing sexy about it. So to unburden myself from the woes of being a politician, I try to stick to some ground rules: Put your money where your mouth is Don’t wear a suit (it would get dirty in the trenches when you’re spending valuable time with the civilians) Don’t call your co-workers, users, or other valuable people civilians. We’re all in this mess together Hold on to your beliefs for dear life Call yourself an influencer. It has a millenial ring to it, so why not? Cloudy with a 99.9% chance of having too many cooks in the kitchen Product Managers come in different colours, flavours, role descriptions and even job titles. Regardless of labels, there’s one thing we all have in common: we have to ‘manage our stakeholders’. There’s a lot of great content out there describing what that means and how to approach it . Truth of the matter is: if you’re in any type of Product role, chances are high you’re working on something very visible. Something everyone cares about. Stakeholders are the ones that can make or break your work. They are the ones we should focus on, internally. So let’s definitely not stop learning how to work with and alongside your stakeholders. Otherwise we might not succeed as Product Managers. However. However. (It’s a BIG however so I just had to put a second one here.) What I rarely read about is all those other people. The ones who are not stakeholders but who all feel they should have a say. I’m talking e-mail threads about the shade of blue of a button in which people are added and added until the “to:” field contains more text than the body. I’m talking people spreading vague product ideas (of their own) as facts and thus causing confusion, disarray and misalignment. I’m talking meetings with 10 people in the room while there should have been 4… At one point I’ve felt like even the office dog was meddling with my stuff. And that her smelly input was more relevant than some of the e-mails I was deleting. I mean receiving. This stuff happens on a nearly-daily basis and it sucks. Big time. But it’s something we have to deal with. If you’re like me, you’ll have days where you just want to take your coat and leave, not wanting to deal with this cr@p. Just remember: These people, however annoying, (mostly) mean well Step up once in a while and call an end to the never-ending e-mail thread or meeting attendee madness. We’re perfectly positioned to notice when chaos is hurting the day-to-business. Use this position to kill the chaos. Everyone, especially you, will feel better. If people keep interfering with your work instead of theirs, something else might be wrong. Take a pillow, place it over your nose and mouth and shout some profanities. Then start a few conversations to see what’s going on and how you can solve it together. If all of the above fails: take your coat and leave. Tomorrow is another day. Soooo… who is calling the shots, you ask? It depends. One thing’s for sure: some days being a Product Manager is all about sporting a pair of big balls. Other days it’s about putting your ego in the fridge and going with the flow. To quote one of my favourite TV shows of all times: “Welcome to Product Management. It sucks. You’re gonna love it! T his blog post was originally written by Samia over at Medium. You can check out the post here and Samia’s profile here .

Reading time 3 min

Dorien Jorissen

A couple of months ago Dorien from Marketing asked me to write a blogpost about my first experiences at ACA Group. Now the roles are reversed: “Dorien, may I share my experiences?” I could write many pages on my experiences from the past 6 months, but I’m not going to do that. I would rather talk about the topic “Digital Transformation: Buzz or Hot?” Digital transformation During the last few months, I have participated to many events, talked to experts and clients, … Digital transformation is possibly the most discussed term of the moment ( besides GDPR of course). One way or another, every organization and every employee is “confronted” with it. Digital transformation (DT): “what does it mean for my organization, when do I have to start it, what does it mean for my job and what will it cost?” It’s very clear to me that there are two kinds of people (putting it very black-and-white for a moment). One group considers digital transformation as a buzzword. Let’s call them buzzers . Another group has a somewhat anxious view on digital transformation. Let’s call them hotters. 😉 The next technological wave I believe that we – as a community – should indeed evolve to a higher level. Call it the next technological wave . But of course, it’s difficult, almost impossible, to predict what this will mean for the future of an organization. On WebTomorrow, one of the speakers put it into words very nicely. "The technological revolution increases at a faster and faster pace. For people / employees, it means that acquiring new skills becomes necessary.” Self-education is and remains of the utmost importance. There are truly some incredible, innovative technologies: Chatbots, AR, VR, AI, IoT, … Not thinking about where to start would be simply irresponsible. But as with any evolution, it’s even more important to start at the beginning. The (digital) future In my opinion, companies should start thinking about how new technologies can truly add value to their organization and employees as soon as possible. But how do you stay up-to-date on all new trends, possibilities, … and what would it mean to your organization? A partner is indispensable for this. Look for a partner that deals with the digital transformation of business processes on a daily basis. Consider them as an extension of your IT department. And of course, involve your own employees as much as possible. Reassure the hotters . Digital transformation doesn’t imply immediate job loss. It means eliminating paper and letting employees focus on what they love to do and what they’re good at. The term digital transformation is possibly a bit buzz , but also emphasize to the buzzers that the next technological wave is a crucial factor that may not be underestimated. Some companies have already done a lot, but that doesn’t mean that they are finished with their digital transformation. It’s an ongoing process. And of course, other companies haven’t done anything yet. That doesn’t mean that it’s already too late: embrace it, study it and do something with it. Digital transformation costs money, but it’s not a real cost. It’s an investment and, as with any other investment, a positive ROI is intended. So, start as soon as possible. Look for a partner and discuss the possibilities. Focus on the low-hanging fruits and gradually grow to a higher level. Just another opinion This blog is no science, but it’s how I look at digital transformation. An opinion like many others and of course opinions should be shared. I’m very curious about what your view on digital transformation is. Are you part of the Buzzers or Hotters ? Do you want to discover what your company needs for digital transformation? Contact us through the ACA websit e and we will certainly help you along

Reading time 4 min

Dorien Jorissen

There are only a few days left until the GDPR goes into effect and an alarming amount of people are panicking and wondering how they can save their marketing and sales from it. But why does everyone feel like that, when in fact, the GDPR is actually saving them? GDPR won’t crush your marketing sales dreams The most important thing we’ve done at ACA IT-Solutions concerning the GPDR was finding that much needed clarity. We have been fortunate enough to work with an amazing external GDPR consultant (if you are reading this Jean-Pierre, thank you for all the help!), who made it all very clear to us and which made me realize this: GDPR will not crush your entire marketing and sales dreams if your company is customer-centric and focuses on delivering value. I am not saying that it wasn’t difficult for us. Being compliant meant a lot of work and will still mean hard work in the future. But we needed to make changes, which actually make a lot of sense. Here’s why I think GDPR is actually a superhero to marketing and sales. Why the GDPR is a good thing for marketing sales The new rules focus on a few key aspects that will improve and evolve marketing and sales to a higher level. 1. Customer Centricity Customer Centricity and GDPR go hand in hand. GDPR isn’t here to sabotage all marketing initiatives or to just make our lives a little bit harder. It makes us focus on values such as transparency, data quality and respect for the people we contact. The contacts in our databases will genuinely be interested in what an enterprise has to say. CTR rates of your next emailing will probably go through the roof! You might have to process the sting of losing a large chunk of your database in the initial phase, but after a while you’ll be more than happy with the results. And the opportunity to be the superhero of actually useful and interesting content. 😉 2. Privacy GDPR-compliant companies are able to guarantee a feeling of trust to people when it comes to their privacy. It’s a huge plus for them if you are not only involved in their privacy, but are also able to convey how exactly you deal with the matter and which measures you take. Think of all the heated privacy scandals of the last few months, such as the Facebook Data Scandal . It’s the perfect example to show that privacy leaves no one untroubled. A new era has begun when it comes to making personal data publicly available! 3. Build and maintain trust The honesty and transparency that is required in GDPR-compliant communication allows marketers to once again build and maintain a relationship of trust with prospects and customers. Companies will need to respect the wishes of individuals and need to think about when, why and how people can be contacted. Instead of consumers being suspicious of marketing and sales efforts, we can now guarantee and actually show people our true intentions. 4. Data Quality The dialogue marketing stemming from this new legislation provides individuals more than ever with a voice and makes it easier for them to contact a company. The GDPR also increases the quality of your data. Companies will not only look whether data is correct, but also at the way they gather and process it. This is unmistakably a big benefit for the quality of the CRM you’ve built up. After all, qualitative and GDPR-compliant data take you to the next level when it comes to the use and maintenance of data within the different departments of company. In short, it makes us consider ‘doing business responsibly’ in a whole other light. 5. Security The new legislation and its data security requirements have established worldwide awareness concerning the importance of investments in security and privacy. Businesses all over the world are: integrating IT-governances, examining the security of their data, thinking about Privacy by Design , preventing data breaches, making data risk assessments, ... Instead of being the violator, organizations now have the opportunity to be the protector of personal data and privacy. An important step that was long overdue. The GDPR has the potential to make us better in every way In my honest opinion, the only real conclusion I can make is that the GDPR has made companies not only think about their responsibility in data privacy and security, but has also led to companies taking real action. GDPR is simply an evolution that can make any organization stronger, smarter and more self-aware. ACA’s commitment to the GDPR I already mentioned we first looked for clarity concerning the GDPR at ACA. After understanding the legislation, we needed to fully commit ourselves to it. Of course, marketing and sales aren’t the only domains within ACA that commit to the new legislation and our view on privacy and security. That is why we created an internal GDPR mission statement , which we hold in high regard throughout our company’s activities. “Faithful to its core values, ACA Group continuously strives to be an honest and discrete leader in data privacy protection, treating all personal data in our ecosystem in an ethical, respectful and pragmatic way.” — Ronny Ruyters , CEO at ACA Group Interested in our GDPR policies? Go and have a look at our renewed legal page and don’t hesitate to contact me if you have any remarks or questions or just want to chat.

Reading time 5 min

Dorien Jorissen

We all know you can use Jira Service Management for your IT helpdesk , but did you know you can also use it for facility management? No? Then you definitely didn’t imagine you can rent forklifts, scissor lifts and pretty much anything with Jira. In this blog post, I’ll show you how we took Jira Service Management to a whole new level when it comes to possibilities and integration. Setting up Jira Service Management Our customer Clarebout , one of the world’s largest potato products manufacturers, wanted to onboard their entire plant operations onto Jira. As a farmer in my free time myself, I just couldn’t say no to that. We started with the IT helpdesk and kept it simple, but effective. Since helpdesks are at the core of Jira’s competence, this was a smooth process. (The screenshots below are in Dutch, English isn’t the main language at Clarebout.) Facility management in Jira Service Management After having covered the company’s IT department, we moved on to its facility management. We set up a service desk to report things like a hole in the floor, broken glass, faulty lights, and so on. Since Clarebout’s facility in this case is a food processing factory, risk based priority setting is one of the most important features. An incident’s reporter can set 3 factors (Severity, Exposure, and Probability) that we use to calculate the global risk of said incident. When the risk is too high, we shut down the plant. No potato is worth risking a human life! For IT infrastructure, plant locations and other CMDB data, we used Mindville Insight and some custom scripting combined with Lansweeper for population. As I have my own farm and tractors at home, I really was in my comfort zone at Clarebout. So much so that I (together with the stakeholders, of course) decided to take Jira to new heights, literally. The next thing I was going to focus on was equipment such as forklifts and aerial work platforms. Equipment management First, we wanted the employees and external partners to be able to rent the needed equipment to do their maintenance in the facility. After choosing a type of equipment, renters need to specify their requirements like height, whether the equipment requires fridge resistant oil, where they’ll be needing it, and so on. Once the order is approved, the renter can collect their equipment at the security office. This is where things really got fun: all employees need to have a valid certificate to operate the equipment. In order to securely oversee who has a permit to operate certain equipment, we imported every employee’s data in Insight. The system then conducts the necessary checks when someone requests a piece of equipment, and only if they are allowed to operate it does security hand it over. An important part of running a renting business is planning. This is where Structure and Structure.Gantt come into play. The Structure.Gantt app allows us to visualize, track and manage equipment in easy-to-use Agile Gantt charts. In short, it provides us with a clear overview of which materials are onsite, reserved or in use. (The image below is blurred to protect our customer’s privacy, but should give you an idea of what it looks like nonetheless.) Cool stuff, don’t you think? But why stop there? Reporting broken equipment Aside from the renting part, the company-owned equipment is spread all over the facility. And as with all equipment, they need maintenance or sometimes they just break and need to be fixed. Luckily, users can easily report broken equipment through Jira. Insight allows us to use a location-based selection of equipment. Therefore, the first step to report a broken or damaged piece of equipment is to select where exactly in the factory you are, and based upon that location, get a limited list of forklifts at that specific location. This way, users don’t have to sift through endless lists of equipment before reporting a problem. After selecting the appropriate equipment, users define the problem and mark whether it is damaged or just malfunctioning to complete the ticket. Jira then automatically sends the ticket to a third party depending on which malfunction it is: tyres go to a tyre company, general things to the vendor, batteries to the battery specialists, and so on. With Elements Copy Sync , we created a linkend and a synced issue in the teams/vendors project. That way, the teams or vendors responsible for working on fixing a piece of equipment can get to work ASAP. So, users can report damage to for example a forklift or a building. But what about linking these events together? Of course that’s a possibility, but in a more ‘traditional’ way than what you’re probably thinking of. Users just have to click on their inside location and see what tickets are open on that location. If there’s a damaged forklift and you got a damaged gate, on the same day, at the same location… 1+1=2. 😉 I hope you enjoyed reading this, because I had an awesome time implementing it! If you want to see what else we did with Jira at Clarebout, you can always read our case study here . Interested which Atlassian solutions we might offer you? Check out our Atlassian services! {% module_block module "widget_73256e0c-c9d0-434a-8ac2-1f2d113ce6c9" %}{% module_attribute "buttons" is_json="true" %}{% raw %}[{"appearance":{"link_color":"light","primary_color":"primary","secondary_color":"primary","tertiary_color":"light","tertiary_icon_accent_color":"dark","tertiary_text_color":"dark","variant":"primary"},"content":{"arrow":"right","icon":{"alt":null,"height":null,"loading":"disabled","size_type":null,"src":"","width":null},"tertiary_icon":{"alt":null,"height":null,"loading":"disabled","size_type":null,"src":"","width":null},"text":"View our Atlassian service"},"target":{"link":{"no_follow":false,"open_in_new_tab":false,"rel":"","sponsored":false,"url":null,"user_generated_content":false}},"type":"normal"}]{% endraw %}{% end_module_attribute %}{% module_attribute "child_css" is_json="true" %}{% raw %}{}{% endraw %}{% end_module_attribute %}{% module_attribute "css" is_json="true" %}{% raw %}{}{% endraw %}{% end_module_attribute %}{% module_attribute "definition_id" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "field_types" is_json="true" %}{% raw %}{"buttons":"group","styles":"group"}{% endraw %}{% end_module_attribute %}{% module_attribute "isJsModule" is_json="true" %}{% raw %}true{% endraw %}{% end_module_attribute %}{% module_attribute "label" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "module_id" is_json="true" %}{% raw %}201493994716{% endraw %}{% end_module_attribute %}{% module_attribute "path" is_json="true" %}{% raw %}"@projects/aca-group-project/aca-group-app/components/modules/ButtonGroup"{% endraw %}{% end_module_attribute %}{% module_attribute "schema_version" is_json="true" %}{% raw %}2{% endraw %}{% end_module_attribute %}{% module_attribute "smart_objects" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "smart_type" is_json="true" %}{% raw %}"NOT_SMART"{% endraw %}{% end_module_attribute %}{% module_attribute "tag" is_json="true" %}{% raw %}"module"{% endraw %}{% end_module_attribute %}{% module_attribute "type" is_json="true" %}{% raw %}"module"{% endraw %}{% end_module_attribute %}{% module_attribute "wrap_field_tag" is_json="true" %}{% raw %}"div"{% endraw %}{% end_module_attribute %}{% end_module_block %}

Reading time 5 min

Dorien Jorissen

This is a dangerous post. It could – again – trigger some discussions on the internet between pro and contra Agile. Although these discussions are sometimes fun to read, that is not the goal here. In this post, I want to show some fundamental differences between traditional and Agile methods. Traditional meaning Prince2 , PMBok and in lesser extent ITIL ; Agile meaning Scrum, XP and Kanban. The underlying fundamental differences became obvious to me when I did a study to combine Scrum and Prince2. The conclusion was that as long as you stay on the higher level, you can combine both. In most cases you’ll use Prince2 around the team, and Scrum in the team. But once you go into detail, it doesn’t add up anymore. Why? Let me explain with one example. Prince2 talks about RACI-models per role: long lists of tasks of a role with an extensive description. In Agile, we don’t do that. The team is responsible, without describing roles into detail. This one example shows that the Agile philosophy is different from the philosophy of Prince2 or PMBok. Prescriptive vs. adaptive "The traditional project management methods are more prescriptive; the Agile methods are more adaptive.” The Prince2 foundation manual counts 199 pages. The PMBOK manual counts 188. In both manuals, there is an extensive description of almost everything: roles and responsibilities, what documents should be delivered, staging, work packages, planning, etc. This way, they are quite easy for the project manager to implement. If you know the book, you will probably be able to run a project, which is only possible if most project actions are described in detail. So, Prince2 and PMBOK are prescriptive methods. A prescriptive method has a clear, very structured and formal description. It clearly determines rules, roles, deliverables, etc. (Just count the number of times I used ‘describe’ in this paragraph.) Prescriptive = "making or giving directions, rules or injunctions" Pre-script-ive = "writing before or upfront" The Scrum guide counts 16 pages. Scrum is a framework with a limited set of rules. There are 2-3 roles, 2 documents, a couple of meetings, and that’s it. You can explain it in half an hour, and you can then start with the method. It is harder to implement, though. It requires more of you as a project manager. The difficulty lies in the adaptiveness: it is not fixed. You’ll have to find out how to manage this specific project, during the project itself, for this specific context. Introducing Agile needs extensive coaching, because it requires more guidance. So, Agile methods are adaptive . An adaptive method looks more like controlled chaos. We experiment with the method through formal feedback moments. There is a minimum set of rules, roles and deliverables. Adaptive = "readily capable of adapting or of being adapted" Adapt-ive = "able to adapt" This does not mean one method is better than the other. But it does mean there is a fundamental difference . On one side there is a detailed set of responsibilities per role, and on the other side a rather vague set: a combination is not possible. The same goes for a detailed upfront planning and a highly reactive planning: you can’t combine them. It’s like being a fundamental Catholic and atheist at the same time: it is just not possible. Similarly, you cannot be prescriptive and adaptive at the same time. It means you have to choose between Agile and traditional. If you combine both, you implicitly choose. Either you choose Agile and adapt Prince2 to match (which then isn’t Prince2 anymore), or you choose Prince2 and adapt Scrum to match (which then isn’t Scrum anymore). Predictive vs. reactive " The traditional project management methods are more predictive; the Agile methods are more reactive.” Prince2 and PMBok focus a lot on planning. With these approaches, you plan work packages and stages rather far into the future. Risk management and the corresponding mitigation are also important parts of the method. You predict risks beforehand; the PM tries to think about possible solutions. It smells a lot like ‘controlling the future’. Prince 2 and PMBok are therefore predictive methods. They are a plan-based approach. They predict risks and make precise plans. Predictive = “to state, tell about, or make known in advance, especially on the basis of special knowledge” Pre-dict-ive = “pre-say-able, predictable, ‘plan’able” Agile methods also predict, but in a different way: by measuring the past, and extrapolating that past to predict the future. There is not much upfront risk management. We solve problems when they arise, because we just don’t have enough context at the start of the project. And about planning: changes to a plan are no problem, we take those into account. Agile methods are therefore reactive . They are more an action-based approach. The plan is accurate, but not extremely precise. Here, you will also have to choose. You cannot have both an upfront planning and an action-based approach or do extensive risk management, only to throw it away because you’ll solve problems when they arise. Reactive = “tending to be responsive or to react to a stimulus” Re-active = “action on reaction” Command control vs. collaboration “The traditional project management methods are more a command control model; the Agile methods are more based on a collaboration model.” In traditional methods the project manager is responsible for the project. The team executes (= hierarchical structure). Metrics and formal documents measure the progress of a project. The PM uses the metrics to check (control?) the team. Traditional methods match more with a command control model. This model is better when dealing with repetitive tasks. In Agile teams, there is no such thing as ‘the manager’. However, there are facilitators to help with the extensive communication within the team. The team has a lot of responsibility: they get authority and can make decisions. The model is based on trust between all stakeholders. Agile methods match with a collaborative model. This model is better for complex problems and creativity. It’s becoming boring… Again: you have to choose. You cannot have an empowered team and a project manager with extensive responsibilities. And that is also the overall conclusion: choose. You can’t have both.

Reading time 3 min

Dorien Jorissen

A select group of people nowadays still tends to think that being a designer is just about “pushing pixels”: making stuff look pretty. Add some unicorns covered in pixie dust and everything is going to be alright. Of course, as designers we need to have this skillset, but we also need to have a critical look on so much more. Our creations will be steered by our clients, must be designed for users, and last but not least, shall be implemented and maintained by developers. This blogpost reflects my view on designing for the IT sector . As a designer at ACA Group , my main goal is to create intuitive flows with clear navigation patterns to display the most relevant content to the user. To start a creative process to accomplish this, I like to stick to a good old friend: pen and paper. Sketch out some flows, discuss, erase, restart, … Research design patterns, collect smart solutions for certain problems, ask yourself a dozen what-if’s. And still, without going too theoretical on design principles, is this what truly makes your creations a legit “good design ” ? Probably not, but combined with the following guidelines in the back of my head, I find myself getting closer to a successful design flow. Good design is invisible When a user isn’t aware of the design, it indicates that it already succeeded. In pretty much all cases, that’s when the user has reached his/her goal in an easy, unobstructive and intuitive way. Content is king, but what’s content if you can’t get to it? Good design ideally comes without a manual and doesn’t have to explain itself to its users. As a designer, the user's goal is your goal, but the journey is your playground. Good design is guiding Speaking of goals, one of my most asked questions for clients is “What do we want to accomplish?”. One of my least asked questions is “How do we want to accomplish it?”. That’s where the designer kicks in, by translating the client’s needs while maintaining user likes. You may work for a business, but their users have a key role in keeping them in business. Let’s take this to a real-life example: when visiting the museum (client), a good guide (designer) always has an interesting story to tell, speaks in a clear, understandable voice and is likely to be extremely passionate and knowledgeable about the content. The combination of those will influence the engagement rate among visitors (users). As a designer, be the correct but non-boring guide to engage users. Good design is maintainable Picking up on the museum part: we are all aware that no matter how good the guidance, information can get lost in translation. That’s why a good relationship between designers and developers is key to preserve a project’s intuitiveness and aesthetics. Since static designs evolve into dynamic environments, there will be unforeseen situations. To tackle these kinds of situation, you need to involve the development team early on. Show enthusiasm and educate them on certain design decisions. Provide a style guide and define the reusability of components. Most of all, talk about context and maintaining harmony, as their primary goal is enabling content to be paired with the design. It’s a beautiful co-operation that requires both parties to dive a little deeper into each other’s daily activities, but it definitely pays off in the long run. As a designer, provide context and be the evangelist for your creations. Conclusion To recapitulate on my writings, you can sense that in a way, a lot of submergence is necessary to provide a great user experience. Explaining to your client that you’re designing for their users and not for them is sometimes a hard task. Handing over your designs to a developer involves a lot of trust and may need some guidance. But overall, the right foundation for designing a project is (in my opinion) based on the following 3 layers: The user’s goal is your goal, but the journey is your playground. Be the correct but non-boring guide to engage users. Provide context and be the evangelist for your creations