8

The simplest answer to this will likely be the answer you least like. Don't... In the last fifteen or so years we have seen an ever increasing level of transparency in the work place. This crosses all industries, all job levels and all work styles. Agile hasn't gained the traction it has because it is the best methods of development ever. Agile has been ...


7

Skips the Tools; Build a Process You describe your current process like this: Get order, a lot of communication with files that specify the details, delivery, more communication on setup and support. Then it can be years and the software needs to be updated according to new specifications and the communication starts again before a new delivery. While ...


6

Scrum is not Agile. :) It is one way to do agile, it doesn't fit all situations. Based on what you've described, a straight Kanban approach is going to work much better for you. When supporting a live service, when you need to make a change, it is often something that needs to be changed "yesterday". Waiting for the next sprint to add it to the backlog is ...


6

As far as I understand the question, and if you allow me some humor, you want to know if it is ok to change a pseudo-chaotic (non-)process into a highly bureaucratic PMBOKful one at once. Based on my experience the answer is no, for several reasons: The team is not trained in such a heavy process and it will take a long time before they are efficient. Not ...


5

While I can't give you a specific idea about it being too early, I'd suggest strongly making sure that your team fully appreciates the concepts of agile development and also wants to have a useful process in place. Right now I am working on a team of 4.5 (3 full stack devs, an intern, and me, the PM/BA). I wanted to get us started with the agile concept ...


5

If you reduce or remove a non value adding activity the overall outcome won't change, but the process time will be reduced. Often the non value adding activities take some time, but they can be caused by unnecessary transportation, doing things again etc. In Lean production they are called waste. A couple of examples: corrections: when you have to fix ...


4

Kanban for maintenance and Scrum for development What would be the best way to manage this team so the load is level across all resources, we work at a sustainable pace, and we have a somewhat-defined goal to guide our development efforts? If I were you I will start with the following straw man proposal and refine it from there: About half the ...


4

TL;DR Fix your process problem, then look again at your available options for automating it. Don't Violate "CodeGnome's Law" CodeGnome's Law says: If you can't do it by hand, then you can't automate it. Automation is a tool to increase consistency, but it is not in itself a substitute for a well-defined process or process control. Your current process ...


4

Walk the Process Don't be lazy; walk the process. You're trying to find a technological solution (e.g. cameras) rather than just following the current process to build your diagram. Especially for deeper detail levels such as hand-tracking, you will find it difficult to accurately identify waste without actually performing the process and getting a first-...


4

The contract type is another factor to consider. A firm-fixed price (FFP) contract can provide you the opacity which is your stated desire. The specification is set in the statement of work or statement of objectives. The product is evaluated for acceptance against the specification. To cut against opacity, the buyer can require "key person" clause requiring ...


4

Excessive complexity in processes is called "Red Tape" You can see the Merriam Webster definition of red tape here: Official routine or procedure marked by excessive complexity which results in delay or inaction. The term originates from the red tape formerly used to bind legal documents in England. You can see the Wikipedia definition of red tape here: ...


3

TL;DR You should continuously inspect-and-adapt your entire system as an integral part of running a successful Kanban implementation. To successfully manage growth, you will need to make changes to your processes if you expect to reduce (rather than increase) lead time as your input queues grow. Workload as Empirical Data Kanban is a great framework for ...


3

TL;DR One way to think about project management is that it isn't necessarily about adopting a specific process, framework, or set of practices. Rather, it is most often a tool for managing expectations and making sure that project-related communications are effective. It is never too early to manage expectations, or to start communicating effectively. The ...


3

Requirements gathering is part of the manager's job, and how it is done depends on both the company culture / current processes, the experience of the manager in the specific field of the project, team members' experience, etc. If you want to introduce more formal planning part, start small. Start with gathering the minimal set of requirements your team can ...


3

Based on past experiences, I would agree with the other posts above and recommend starting with a flow-based approach like a kanban board for the ongoing support apps, and maybe look at Scrum for the ones in heavier ongoing/feature development. I would also recommend starting with a board that matches your actual step by step flow and not an idealized flow, ...


3

Joel spoke well. As someone with this same issue, however, here's how I approach the dilemma: Relationships, not abilities, matter. I only hire excellent people, engineering or otherwise. So my goal with employees, most of whom are contracting through me, is to have an excellent working relationship with them. If they want to leave, that's too bad for me, ...


3

Since you're arguing for a situation where (at least some of) your employees will benefit from the anonymity, I can only think of one option: Code Names Create a culture of 'ninja squads' or some similar metaphor on being super-talented. All your devs are remote, so they won't cut though it F2F. You can instill each, individually, with the way that the ...


3

Bureaucratization Tendency to manage an organization by adding more controls, adherence to rigid procedures, and attention to every detail for its own sake. Red tape is about right, but it refers to the outcome not the process. I found Bureaucratization here. This is the correct meaning but the word is a mouthful and certainly not commonly used.


2

I heartily agree with Matthias in his suggestion for a Kaizen driven improvement process. You indicated that there won't be too much push back from the team when implementing you SDLC, but you do need to get buy-in from your stakeholders as you implement the process. I'd recommend that you take several steps to build a strong process with the team: Bring ...


2

If you're okay with a self-hosted option, you could try activeCollab. It's great because it allows you to manage all your projects in a centralized space (including communication, milestones, checklists > sub tasks). As for attachments, while it has a 2MB limit, you could simply use a ftp server and reference the links/paths in your notes. So using your ...


2

My team (7 members) works very well with Google Docs + physical board + Bugzilla. We keep the backlog online in the docs, use the physical board for the current tasks (sprint) and the Bugzilla for all the communication history, files, resolutions, etc. supported by an e-mail server, i.e. everyone receives an e-mail copy when anything is added to the ...


2

Definition of a Project Google's dictionary yields the following as the primary definition of a project: An individual or collaborative enterprise that is carefully planned and designed to achieve a particular aim. The "particular aim" part is important. Without clear deliverables that provide value to someone (a.k.a. stakeholders) then it's ...


2

One of the principles of good project management is to tailor your approach to the needs of your project. Looking at it from this perspective you should always have a PM process, the question is more along the lines of how formal it needs to be for the current project. By all means develop a culture that embraces PM, but trying to implement and enforce some ...


2

To get to point B, you are going to have a process. The question really is, do you want to think it through and formally design it, with control points, rules, assignments, and expectations, or just wing it. There are benefits and costs/risks to both alternatives. What you will likely find is your performance will be less than desired. That will trigger ...


2

Indeed, a flexible shared calendar could help. Check out Teamup Calendar, teamup.com. Some of the setup work you'd need to do include: Add one calendar for each tutor and each student. Limit the time range from e.g. 9am to 5pm, hide weekends, all configurable in the Settings. Teamup allows unlimited number of access links with cutom access rights, which ...


2

Scheduling is actually an NP-hard problem. That's a fancy computer science way of saying there's no way to produce the best solution for any non-trivial schedule before the heat death of the universe. There are a number of algorithms that will render "good enough" timetables in much shorter times. The commercial and opensource scheduling programs do that ...


2

Who is your Product Owner? To me, it sounds like what you are struggling with is that you don't really have a product owner defined for this software. When doing software development, even if you're writing software that is market facing, someone has to represent the product ownership role as you develop your software. Otherwise, you're developing ...


2

From my experience in managing new product development, I think the first step should be to find a launching customer. No launching customer = no reference case, no inside knowledge, IT-driven product, will hardly succeed in a satured market. In your case I would recommend finding at least two launching customers that are willing to spend time and money, ...


2

All such projects should start with a Business Case (BC). The BC should state the problem you want to solve or the opportunity you want to exploit. It should state the cost of undertaking the project (in resource and in hard cash terms) and the benefits that the business believes will arise from undertaking the project. In your case, since the nature of the ...


2

This actually is a very good question. I've found that visual representations of system processes can really help people who don't write code understand system designs. Yet, I've also found people are hesitant to maintain and reuse such documentation. Here I present an incomplete list of reasons why reuse and sharing my be true in the hopes that someone on ...


Only top voted, non community-wiki answers of a minimum length are eligible