Showing posts with label Tools. Show all posts
Showing posts with label Tools. Show all posts

Wednesday, September 27, 2017

Cultural Evolution

I've been thinking a lot lately about organizational culture and how it might evolve. Actually, I've always thought about this and since my entrée into the software world I've applied myself to evolving both culture and process. I've worked through the evolution of tools and practices that enable collaboration. Here is one way I've applied tool improvement to help along the first team I worked with.


This team used a SharePoint list to track work - each work request had an entry and was printed out and handed to the developers with screenshots and a bit of write up about what was to be done. The process worked ok because when you went to the list you would be able to filter it and find your work. There was room for improvement so I jumped right into it like this -


First, I created a view for developers (where assigned to = Me). I shopped this around to other developers and my manager. She saw the potential there and asked for a view for managers. We briefly discussed and I went off and created it.


At the same time the managers changed their practices a bit and started using the views to plan on a weekly basis with quick checkins each morning. Afterwards, it was much easier for everyone to know what they should be working on. Micromanagement wasn't an issue. Managers managed the work flow and distribution, not each individual's work. Having the right tools in place helped with that because they could see right away where things were - no need to hover or constantly interrupt to ask or waste time in meetings that should be used to discuss impediments.


pro tip: Managers need to know how the work is going - proactive updates will keep them informed. Imagine if your mom was in a long surgery and you were left for hours and hours wondering how things were coming along. Or maybe you have something in for repair for weeks with no word about how it's going. It can be troubling not knowing and they've got to answer for those things to their managers or to clients.


Hopefully sharing this experience helps to illuminate the value in having the right tools to track and communicate about how the work is going. This form of passive communication enables anyone to check in on the work without bugging or micromanaging (both counterproductive activities).



Wednesday, August 13, 2014

Process Documentation Style

Finding that I post more on planning and management than on technical topics. This stems from current efforts more than anything.
The main thing I want to cover is that a process is repeatable. If it's not understood and documented, then there ain't no process. Or, as I just found out, it's the components of the business process that do not exist.

http://m.businessdictionary.com/definition/process.html

However, I would state that a process that is different for each individual or instance of input, cannot be defined by a single meaningful process. In order to understand a current process in such state, much effort is required to understand the process from each point of view.

Unless a consistent process has been defined, the process is to collect whatever procedures make sense at the time in order to achieve the outcome.

In some cases, perhaps in a results-oriented environment, ad hoc may be the best approach. This style of process management relies on the individual more than the structure of the process.

There are certain risks involved in taking such an approach including un-repeatable results and inconsistent data for analysis. Another drawback is the increased risk in taking on technical debt, depending on the individual.

The benefits are that the end result can be achieved without following a possibly complex and lengthy chain of procedures - results are dependent upon the individuals involved.

A well-defined process can be implemented in a process-oriented environment. This style is suitable for consistent and repeatable behavior, as long as people are following process.

The major risks are that a process may be ill-defined, overbearing, or not well understood. It may serve to stifle creativity as well as lead people to go off process if it is not understood, is too complex to follow, or if time to results is inadequate to the situation.

The benefits can be great once data is tracked and proper analysis techniques can be applied. Resources can be directed according to analysis, and long-term planning can be better achieved.

Possibly, one of the most important aspects of defining a process would be to keep the long-term goals in mind. If the process becomes heavy for the sake of the process, it may do more damage than good.

Sometimes, tools can limit the performance of a process. Appropriate tooling should be applied to the appropriate process; the process should not be limited or hindered in effectiveness by the tools.