Self Organization and Boundaries

Boundaries mater in Agile

Being a Scrum Master is hard work.  You spend a lot of your time helping others and many times wind up acting as a therapist for the people on your team.  You massage egos, help with nagging insecurities and keep fear and uncertainty at bay.  It is the most rewarding and the most frustrating things you can do.  The most interesting thing I have found over the last few years is it also requires some firm leadership and boundaries.  This week I would like to talk about that discovery.

As I usually do, I spend a great deal of time surfing the web learning about technology and gathering up new ideas to lead my team when I stumbled on to an article in Slate.  Laura Smith in her article “Why I Regret Being a Nice Boss,” spoke about her experiences running a coffee shop in Washington D.C. What struck me about the article was the realization that as a leader some things were just not negotiable.  Employees were expected to be on time and each employee had a set number of minutes for break time.  Those who violated these non-negotiable rules were written up and eventually managed out of the firm.

This made me think about agile principle number eleven, “The best architectures, requirements, and designs emerge from self-organizing teams.”  How can a leader set non-negotiable terms and still allow a team to self-organize?  This is when I realized that when a business or leader sets something as non-negotiable they are really setting boundaries.  Once a team understands what the boundaries are they can organize within them.  For example, a sprint is always a fixed length.  This means all work committed to by the team must be finished by the end of the sprint.  How that work is divided up and managed by the team is up to the team but the work must be finished and that is non-negotiable.

During a sprint the team decides what a good definition of done is.  For the teams I work on, it is the following; unit tests written, code which compiles, code checked into source control, and code pushed to our development environment.  If this this definition is not met then the user story is not “done” and the developers have to go back and finish the work.  This creates some tension with meeting all the sprint goals but it has saved my team numerous hours of headache over the months.

Once the sprint is done, we have used our retrospective to tweak the definition of done for the next sprint to make sure that we are improving.  This keeps with agile principle number twelve, “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts behavior accordingly.”

So being a firm, fair therapist is what you should strive for as a servant leader of your software development team.  By setting boundaries, you give your team a safe place to experiment and thrive.  You also create an environment where everyone knows what is expected and how they can succeed.  This isn't always the nice approach but it will make everyone feel better at the end of the day.

Until next time.

Graduating from BizSpark

Proud to have graduated from BizSpark

This week marks a special anniversary of sorts.  Three years ago I became a Microsoft BizSpark member.  This week I graduate from the program.  It has been a peculiar journey but I feel that I have learned a great deal.  I would like to discuss my experiences with the program.

I was between consulting jobs and was attending an ALM conference in Chicago when I asked if there was a program for a Microsoft professional to get Visual Studio in order to start building a software start-up.  I was quickly directed to the BizSpark program and I have not looked back.  I was provided with software licenses for Office and Visual Studio.  I was also given a network to share ideas and solicit for help.

It has not been perfect.  Sometimes I have felt alone in the wilderness of business.  The clients I thought I would get just by putting out a shingle have been elusive.  Still, I have been able to migrate from Visual Studio 2010 to Visual Studio 2013 and keep up on all the latest technologies.  I am now comfortable with MVC thanks BizSpark.  I have embraced Microsoft Tag until Microsoft decided to abandon the technology and thanks to NuGet was able to generate my very own QR codes to manage my business.

Plenty of ups and downs and BizSpark has been there for me.  Now I am officially an alumni of the program and I hope that I get an opportunity to follow in the footsteps of another member WhatsApp.  I understand that this is pie in the sky thinking but that was why I wanted to be an entrepreneur in the first place.

Feel free to contact us and learn more about our business.  I want to take time out to thank Doug Crets and the BizSpark team for sharing my work with others and keeping my focused on the end goal which is quitting my day job and putting other people to work.  I look forward to letting everyone know when that happens.

Until next time.

Patterns in the Code

Square Pegs is round holes. Could be design patterns

I spend a great deal of time reading other peoples code.  It is part of my day job as a Scrum Master.  It is also what I do as the president of E₃ systems.  It is a tedious task sometimes but I recommend it for every developer working today.  This week on the blog, I want to discuss code patterns and why they are important for any developer.

In the world of literature, there are countless critics and competing schools of literary thought.  Fortunately, the world of computer science does not have that problem.  The most important standard for software is that it works and that it meets the needs of customers.  This is changing as software becomes more complex and it has become more important to the operation of the business.  Standards cropped up thanks to this new reality and I think it has been a good thing for the industry.

Developers in many respects are like painters; they are creative, temperamental and a little crazy.  Ask two developers to write the same software with the same requirements, you will get code that is written very differently.  Multiply this by several hundred developers over three continents and you have a recipe for disaster.

Most coding standards are fairly common sense.  I personally like the standards from Microsoft regarding C#.  However, I am starting to see some troubling trends.  First, the Gang of Four, design patterns for Java are being used as a cudgel to punish self taught developers.  These design patterns have been taught in computer science classes the last ten years and the original book on the subject came out in 1994.  Today those patterns are used in numerous development languages.  A good developer with an understanding of the object oriented development doesn't need to use these patterns but some architects and a sizable minority think they should be the necessary grammar of development.

I strongly disagree with this position.  Gang of Four design patterns are a style of development not the last word on the subject.  To barrow from my friends in English and Communications theory, the Gang of Four represents a dialect of coding rather than the grammar.  Just like the formal language of a court room is different than the informal tome construction workers use on the job site.  There is a time and place for both and slavish devotion to design patterns make about as much sense as using a hammer to drive a wood screw.

Software developers often that they are artists but in the real world they are often being used like animators helping create large and complicated pieces of work with an almost infinite number of moving parts.  The Gang of Four design patterns are helpful but are being misused by a minority in the development community to judge the ability of other developers who do not understand these processes.

I am much more open to the SOLID programming approach which creates general guidelines for flexible code.  These guidelines make design patterns possible but not necessary.  If you use SOLID are more likely to write cleaner and easier to use code.  Furthermore, this approach instills good habits in both self-taught and classically trained developers.

A developer is his own worse critic.  I know that I look at code I worked on three years ago and cringe at my lack of technique.  I think I am a better developer now than I was when I started fifteen years ago.  I may not use design patterns but I think that I can create satisfying customer solutions.  In the end, that was why I wanted to be a programmer in the first place.

Until next time.

The Quality Goes in Before the Software Ships Out.

I think we need to explain.

This has been an amazing week of transition for E₃ systems.  We have formally been in business for three years.  We are also on the cusp of a new software release. Today I want to talk about our new product Tony and why you will have to wait a little longer before it goes live.

Early in 2013, a potential client called us out of the blue and wanted to know if we could put together a simple contact management system for them.  We rushed a prototype out and demonstrated it to the client.  They seemed enthusiastic until we gave them a contract and said that they would have to pay for us to finish the project since it was done on spec.  We never heard from that client again.  I suppose this was a good development because if they were not going to return our calls or honor a contract I am sure that getting paid would have also been a serious problem.

The months of March and April were gloomy as we continued to sell our main product Sully 2.0 and assess the failure of our prototype project.  Some good did come out of the work because; we developed experience in MVC 4 and Entity Framework code first for rapid project turn around.  By May, we had come up with a new project and idea which we nick-named Tony after a famous Fiat mechanic.

Tony would be an easy to use system to track maintenance for vehicles in any sized fleet. Trucking companies, rental firms, and even car dealerships could use the system to keep track of when and where work was done.  It would become a living record and best of all it would obey the philosophy of all products at E₃ systems.  It would work on a smart phone, tablet, and personal computer.  We also leveraged the power of Microsoft Tag so someone in the field would scan a code on their phone and get instant information.

We had scheduled that Tony would launch in July of 2013.  It was a hectic schedule made even more dramatic by the server migration we did to upgrade our software and databases.  Something had to give and it was clear that the migration took precedence and that we would have to push back the release of Tony.  We also felt that we needed to do more work on the product before it was ready for release and sale.  I am deeply disappointed about this but as the president of the company I would rather ship quality software that release something and then expect my customers to find bugs and act as our quality assurance team.

So we are planning to release our Tony software in mid-September.  I felt that you our customers deserved and explanation.  We had been dropping hints about Tony for the last two months and felt you needed an honest explanation of why it is not here.  As a young start-up we are not in the business of vaporware so please forgive us for the delay.  If you have any questions or concerns please drop us a line and we will have an account executive contact you directly.

Until next time.

Business Solution Architecture Explained

Our coming changes are not this wild.

Architects get a bad name in technology spheres.  At large companies they take on godlike status because management is under the illusion that one fantastic will architect and hundreds of mediocre developers will create great software.  As someone who has worked in those situations, all I can say is that the architect is a distant figure who has no impact on my job other to tell me that the code I have already written is wrong.  When working on large projects my skills did not improve as a developer and when I needed help I was on my own.  The only time I saw an architect was during the code review process and it was more about being demeaned than learning how to code better.

There is a better way.  When you talk about architecture in the construction business you are talking about a person who has an engineering background, who understands construction techniques and actually draw out blueprints of what they need done.  I truly think that every industry can benefit from an architect, if they actually have the skills to help you succeed.  This is why E₃ systems is expanding its focus.  We are going to be changing our web site over the next month and we are going to be talking about how we can help you manage your business.  We are going to become Business Solutions Architects. 

This rather pretentious term means that at E₃ we will help you improve your business processes by giving you expert guidance on operations, technology, and logistics.  A reprehensive will come into your office and ask you about your daily challenges.  We will learn about your pain points in your business and then will provide you with solutions which will make you more profitable.  For example, if you are struggling with logistics we will be more than happy to get you set up with our Sully 2.0 Business Intelligence platform which will help you stay on top of your inventory. 

We are also working closely with an insurance company to better manage contacts and leads.  As we get closer to release we will tell you more.  Our goal is simple we want to help small and medium sized businesses grow and we have the skills to make that happen. 

Reach out to us today and we will tell you how.

Until next time.