Monthly Archives: January 2017

Why Designers Should Use Agile Sprint Planning

Many creatives such as graphic designers, photographers, and product designers live in a world of chaos. On any given hour of any given day, someone in the organization will email, chat, or stop by their desk to make a last minute design request. Could you create this quick poster for our recruiting event tomorrow? Can you squeeze in a design for a new confirmation modal in our the app? Can you create a quick summary video from our offsite yesterday so I can share it with the team tomorrow?

Accompanying the ever-constant stream of requests is a lack of clear priorities. This forces the designer to make emotionally-driven prioritization decisions multiple times per day. Should I prioritize based on who asked me? In that case, does the CMO win because of rank or does the nicest person win? Should I prioritize based on urgency? Is that based on a real or imaginary deadline or perhaps just the sound of urgency in their voice?

Without clear priorities, aligned across stakeholders, everyone loses. Some of the work gets done quickly while other work slows to a crawl–eroding stakeholder trust. Even more concerning is that the chaos starts to negatively impact the quality of the design work. This couldn’t be more true in the world of product design where ad-hoc designs lacking customer research and testing will not only reduce usability of the product but will frequently cause engineering rework down the road.

The end result of this vicious cycle is an exhausted designer, who feels on the one hand like a hero for smiling and saying “yes” to a request and on the other hand feels like an unappreciated short-order cook who just can’t keep up. Get in Touch With us for More Information

Measuring Developer Productivity

Almost as long as I have been working to make the lives of software engineers better, people have been asking me how to measure developer productivity. How do we tell where there are productivity problems? How do we know if a team is doing worse or better over time? How does a manager explain to senior managers how productive the developers are? And so on and so on.

In general, I tended to focus on focus on code simplicity first, and put a lower priority on measuring every single thing that developers do. Almost all software problems can be traced back to some failure to apply software engineering principles and practices. So even without measurements, if you simply get good software engineering practices applied across a company, most productivity problems and development issues disappear.

Now, that said, there is tremendous value in measuring things. It helps you pinpoint areas of difficulty, allows you to reward those whose productivity improves, justifies spending more time on developer productivity work where that is necessary, and has many other advantages.

But programming is not like other professions. You can’t measure it like you would measure some manufacturing process, where you could just count the number of correctly-made items rolling off the assembly line. We help you in measuring Contact us to know more