The difference between a Car shop floor and a software center

Chakravarthy — Mon, 23 Nov 2009 12:22:45 +0000

A supervisor in a Car shop floor can see what a worker is doing by merely looking at what he is doing from a respectable distance. He can measure the cycle time by using a stop clock and comparing it for that workstation against standards. He can hear and see if there is a problem because the worker will swear and sweat and call others. Or the supervisor himself may know enough to see a problem in one workstation. He can measure progress for that shift against daily targets by seeing some overhead visual. The work instructions for each workstation are printed on a sheet of paper, which is easily visible. In any case some things are easy to identify once you see how the work is done. Of course only an expert will know if things are going well, but even a non-expert can pick up a few things by watching carefully.

A software team leader does not have it so easy, unless he goes and sits next to a programmer, or reviews the code that has been checked in to a repository. There is no visual clue from a distance as to what exactly a developer is doing except tapping on the keyboard. Everything including the daily plan, the long-term plan, the milestones, the work instructions, the requirements are all in other computers. For all the team leader knows, the guy on workstation 3 could be developing software to fire a missile and developer on workstation 4 could be developing the software for a missile neutralizer. It is all just a room with wall-to-wall carpets (in cases), wooden cubicles, rows of humans and computer screens. A few papers pinned to each cubicle, which probably has nothing to do with the work that is being done. It is just one big black box, sorry room. There could be some requirement specs. or product documentation but they are probably quite outdated, and are again in some black (or gray or white) computer box. It is like being in the room where you know the murderer is, but just can’t make out who it is.

If the team leader suggests any documentation or test cases or artifacts to give him a finger hold on what is going on, it will again be developed by using some software and stored back in a computer again, deepening the mystery of the whole room. Back to square one. How is a brand new software leader supposed to lead this team of people who seem quite all right without him? With absolutely nothing that he can see or read or understand without tapping one of the developers on the shoulder and asking ‘Can you please tell me what is going on?’ Given the turbulence in software, he will probably be told of some application, which he has not seen before, in a platform he is new to, for a customer he doesn’t know. He is the senior most man standing in that room but the most clueless and helpless. So near and yet so far!

Having been a developer himself, where he knew every line of code in his work and had an idea of what was going on in the neighbor’s code, this is a culture shock. This new leader does not have the liberty of getting his hands dirty because SURELY THAT IS NOT HIS JOB?, Yet he is not sure how to add value as a LEADER (!) when he does not even know how it is all done.

This lack of transparency in what is going on can be daunting to a new Supervisor if he is also new to that domain and activity. The ability or inability of the supervisor to get a toehold in this room full of activity will determine his future in the company. It takes a lot of initiative, self-confidence, and drive for this person to get into the thick of things, even though he may not be one of the developers. This break-in is critical for his self-respect and dignity as a leader. Otherwise he will be a mere postman who has become a team leader as a mark of respect for having worked many years as a developer. That is worse than getting retired! So there is a lot of difference between a car shop floor and a software development center. In the former, everything is out in the open, and in the latter everything is put into boxes called computers.

Why automated tests ?

Chakravarthy — Sun, 22 Nov 2009 13:26:04 +0000

Checklist For A Software Team

Chakravarthy — Sun, 15 Nov 2009 16:06:05 +0000

Assuming that a 5 year old software company ABC, with 10 software people, has developed an application for customer XYZ and maintains it for them, these could be some questions for the developers. There are no right answers for these. It depends on what the team thinks. This is more of an assessment template for current process , rather than a checklist.

Do you plan a project end to end, or iteratively in time sprints ? Which do you find better and why ?	Project planning	A01
How do you know what is ‘quality’? How do you know what is a ‘good process’? Are the steps of this process documented? How are they kept updated and accessible to current team as well as a future team, which takes over? Do you refine your processes to prevent problems as they creep up? How do you improve the processes ?	Quality and process	A02
Review the project(s) in the past which overran cost and time. What were the causes of the delay ? How could you have delivered it faster to the customer and cut back on the time and cost ?	Reducing lead time	A03
How does your team estimate each work item ? Have you tried other options ? Why do you feel this is the best option ?	Estimation	A04
When a developer says an item of work is ‘done’ what does it really mean ? Does it mean it is reviewed, unit tested , acceptance tested and ready to be deployed , or ready to be tested and reviewed ? Which is better and why ?	What is ‘done’	A05
If you had to take a call between schedule, cost, quality, features which one would you compromise on? If someone were to point out quality issues in your projects, which are deemed ‘done’, would you stop your current project and attend to them?	QCD	A06
How can you and your manager and / or customer monitor the daily progress of the project without having to call for a meeting or a phone call? Does the report give the ‘big picture’ as well as the current progress at a glance ?	Project tracking	A07
How does your team find out solutions to problems? How do they know they are attacking the right problem and not just the symptom? How do they know they have covered all possible options? How do they know the option they selected is best? How do they know the option they selected actually works ? How do they know the best practices in each area of their work ? Where is this solution documented? Is it available for others to read and learn? How do you know what problems each person is facing in the work? How do you ensure that these problems surface immediately	Problem solving and dissemination of lessons learned	A08
The above points have frequently mentioned documentation. Is such documentation practical ? Are they worth it ? Will anyone read them at all ? If no, then how can the company retain its knowledgebase and legacy ? If no, how can the company disseminate information? If yes, then what are some simple ways of documenting things ? What are some simple ways of circulating them or presenting them ? If yes, and if any of the above documents were stored in systems and if there was a need to discuss any of them without access to PC’s how would you manage it? Where are these standard available? How often are these standard work documents updated and how do you know it is the latest? Who makes suggestions to improve these standards? How do you know your people follow these standards?	Documenting ‘standard work’ and / or best practices	A09
How can you make your team to be more proactive and aligned with the project objectives without deviating from the standards? Are they trained in the process and its objectives? Are they counseled for behavior? Are they in tune with the thinking of the project manager and yet display innovativeness, which adds value without compromising on basic objectives like quality? ? Are they trained to know where and how they can give ideas to improve the way they do things ? How many such ideas have been implemented successfully ?	Employee initiative	A10
How do you know what you don’t know? How does your team know what options are out there when they consider a specific technical or process related problem? How do you know you are selecting the best option? How much time is spent in training the team either internally or externally? How much are they encouraged to learn ? Are they cross functional? If needed, can one step in for the role of another? Are they fully loaded with work or do they have leeway for more flexibility and learning space?	Training and self learning	A11
If one person or process becomes a bottleneck do you try to release it ?	TOC and levelling	A12
If a new person were to take over the maintenance, development, deployment and operations of this application in the absence of the entire development team, how easy would it be? What steps should that person follow? Will he be able to get productive in each of these areas in 48 hours? If not how much time would it take him? Are these steps documented? Where are these documents stored? If it is in the system, and this person meets your CEO will the CEO know which part of the system this person should access to get hold of this document? Will the CEO know the login and password to your system? How will this new person know the health of the application that he gets hold of? How can he test it rapidly? How does he know it is the latest edition? How do you know this set of documentation is current? Do your own team members use this document?	Hand over	B01
Does your application use a framework? If a new team replaces your team without any handover, how will they know how to use this framework? How will they know why this framework was developed, what were it’s objectives, what were the options considered and why this option was the best? How will this new team be able to rapidly test this framework to ensure it works as expected? How will they get the latest edition? How will this team be able to troubleshoot, or extend this framework quickly and easily? Is the framework documented? How do you know this document is current? Are all the options considered for each part of this framework documented with their respective objectives? Are they current?	Application framework	B02
How do you know your testers are covering all lines of code and all scenarios? How does your testing system report? Will your Project manager be in a position to run the entire suite of tests every time there is a change to test for regression? Will he be able to track the results of the same every time a patch is released? What options have you considered for this? How do you do black box testing, white box testing and UI testing? Where is this strategy documented? How do you know this is current? If your own team decided to rewrite this application in a new platform how easy would it be? What artifacts of the running application can be reused? What would you do now and before the start of the rewrite to make this exercise simple and efficient?	Test usage, coverage, automation and reusability	B03
How do you prevent UI level issues before deploying? How do you know the UI and navigation will suit the customer?	UI design and prototyping	B04
How does your team know they are writing good quality code? How does the process ensure that this happens? Is the team trained in good coding? How do you ensure the design practices of your company are as good as possible? How do you ensure that you do not spend too much time in upfront design and yet keep refining the design as the project progresses? For example what is the exception handling strategy in your project? Is it documented with examples? Which options did you consider and why did you decide this was ideal? How will you refine this exception handling policy as you progress with other projects?	Good practices, refactoring and self inspection	B05
Do you have a set of customer acceptance tests ?	Acceptance tests	B06
How easy is it for a new user to understand your application ? Are there any video tutorials ? How do you train new users ?	End user training	B07
What is the process you follow for gathering user requirements ? What options have you considered and why do you think it represents the best ? How do you break it up into items of work for the team ? How does that help the process ? How do you reduce the risk of ‘it works in my PC’ problems and ‘there is more to this than we thought’ problems ?	User requirements	B08
How frequently does your team check in to the version repository ? How frequently is this code built ? How frequently is this deployed and checked ? Are these automated or manual ? Why did you choose this option ? Is it part of the standard work document ? Do you make source code changes at site ? If you do then how do you synchronize it with office ? Have you thought of other options ? Is this part of standard work document ? How frequently do you backup your version control repository?	Version control	B09
What is your deployment , implementation and support policy ? How quickly and efficiently do you deploy in a new site ? What do you do if the user does not respond in time to your plan ? Do you use tools for remote maintenance ? If not why not ? If so which tools do you use , why is it a good option and is it documented ? Is the deployment automated or not? Why is it so? What reasons led to the decision to automate it or not.	Deployment	B10
Do you conduct periodical security audits of the application and the installation ?	Security	B11
If the customer reported performance issues to one of your developers, what would be the steps he takes to troubleshoot? Is this process documented somewhere? How is this kept current with new learning? How does the developer know how to interpret what he analyses for this problem?	Performance troubleshooting	B12
If a customer walked in on a Sunday and only the CEO was in the office and asked for the latest version of the software, how would the CEO be able to give it to him? If the CEO wanted every milestone release of the application how would he get it? If the server, which hosted the version repository, were deleted, how would the CEO get all these past releases?	Access to archived software	B13
Is there a data backup plan for the customer? Is it documented? Is this document available in the package for the deployment person? How much data loss can the customer tolerate and re-enter in case of data loss? What were the options considered before selecting this backup plan? Why is this ideal for this customer? Is the back up data stored in re-usable media or is it in the hard disk of another system? Why is this option better? Have you tried to shut down the system and restore from this backup?	Data backup	C01
Does your application use log files to instrument problems? What is the logging policy that your developers follow? Is that policy documented in their standard?	Instrumentation	C02
How will the customer know which version of the application is running? Since this is a Microsoft application, do you follow the standard windows style of “Help -> About?” Is this version unique enough to know which patch is applied?	Versioning	C03
If you have a multi site or multi client application how do you plan to push out updates? Will you push updates or will they pull them? Is it manual or automated? Which options have you tried and why is this the best option?	Push updates to clients	C04
Does your customer need database maintenance? If not why not? What is the database maintenance policy that you follow? Is this documented somewhere? What options did you consider before making this standard? How much of this maintenance task is automated? How do you track the adherence to this?	Database maintenance	C05

I am here

The difference between a Car shop floor and a software center

Why automated tests ?

Checklist For A Software Team