The Way of Testivus – Unit Testing Wisdom

Some good advice on developer and unit testing, packaged as cryptic bits of ancient Eastern wisdom in the hope of getting your attention.



The Way of Testivus – Unit Testing Wisdom From An Ancient Software Start-up

The Way of Testivus – How Much Unit Test Coverage Do You Need?


CLR 4.5: .Net Framework Kernel Improvements

In this post I’ll go through some of the enhancements and improvements done by the CLR team as part of the performance improvements in .Net 4.5. In most cases developers will not have to do anything different to take advantage of the new stuff, it will just works whenever the new framework libraries are used.

Improved Large Object heap Allocator

I’ll start by the most “asked-for” feature from the community – compaction on LOH. As you may know the .Net CLR has a very tough classification regime for its citizens(objects) any object that is greater than or equal to 85.000 bytes considered to be special(large Object) and needs different treatment and placement, that’s why the CLR allocate a special heap for those guys and then the poor guys lives in a different heap frankly called Small Object Heap (SOH).

SOH Allocations and Garbage Collections

The main difference between these two communities are basically around how much disturbance the CLR imposes in each society. When a collection happen on SOH the CLR clear the unreachable objects and reorganize the objects again (all citizens of the SOH) to compact the space and group all the free space at the beginning of the heap. this decreases the chances of fragmentation in the heap and it can only happen because the citizens of SOH are lighter and easier to move around. on the other hand when collection occur on LOH ( Only occur during Gen 2 Collection) the CLR doesn’t com[pact the memory cause it’s very expensive process to move these large object around.You see where this is leading, now we have to deal with fragmentation issues in LOH and from time to time a Out of Memory Exceptions.

LOH Allocations and Garbage Collections

Because the LOH is not compacted, memory management happens in a classical way. where the CLR keeps a free list of available blocks of memory. When allocating a large object, the runtime first looks at the free list to see if it will satisfy the allocation request. When the GC discovers adjacent objects that died, it combines the space they used into one free block which can be used for allocation.

Well the CLR team didn’t make the decision yet to compact LOH which is understandable because of the cost of that operation, on the other hand they improved the method by which the CLR manages the free lists, therefore making more effective use of fragments. So now the CLR will revisit the memory fragments “Free Slots” that earlier allocation didn’t use..

Also in Server GC mode, the runtime balances LOH allocations between each heap. Prior to .NET 4.5, we only balanced the SOH.

Many of the citizens of LOH are similar in nature which lends itself to the idea of Object Pools that can essentially reduce the LOH fragmentation.

Background mode for Server GC

Couple of years ago I blogged about a new Background GC in Workstation mode in CLR 4.0 the main idea is while executing Gen 2 collection, CLR checks at well defined points if Gen0/Gen1 has been requested, if true then Gen2 is paused until the lower collection runs to completion then it resumes. Read more about Background mode for Workstation GC.

(.NET 4.5) Gen0/Gen1 collections can proceed during Gen2 GC

New CLR supports Background mode for Server GC which introduces support for concurrent collections to server collector. It minimizes long blocking collections while continuing to maintain high application throughput.

In the above schematic diagram notice the following:

  • As in .Net 4.0 whenever Gen 0 or Gen 1 happen the managed threads allocating objects on the heap are paused until the collection is done.
  • Gen 2 will now pauses on Server mode too (As in Client/Workstation mode) during Gen 0 and Gen 1 giving it priority to finish first.
  • Gen 2 as usual runs in the background while the managed threads still allocating objects on the SOH heap.


.Net Framework prior to v4.5 install both the IL and NGened images for all the assemblies to the dev machines which consumes double the space required or more just for the framework. The CLR team conducted a research to find out what are the most commonly used assemblies out of the framework and named those the “Frequent Set” this set of assemblies only NGened now which saves a lot of space and dramatically decrease the framework disk footprint.


Now the perfectly good question that present itself is What about performance when non-NGened assemblies are used?!

The CLR team introduce a new replacement to the ngen engine called Auto NGen Maintenance Task. When you create a new application uses non-NGened assemblies or it’s not NGened itself here is what happen:

  1. The user runs the application
  2. Every time the application run it creates a new type of logs called “Assembly Usage Logs” in the AppData windows directory.
  3. Now the new Auto NGen Maintenance Task takes advantage of a new feature in Windows 8 called “Automatic Maintenance” where a background efficient performance enhancement jobs can run in the background while the user is no heavily using the machine.
  4. The Auto NGen Maintenance Task goes through the Logs from all the managed apps the user ran and creates a picture of what assemblies are frequently used by the user and are not NGened and which ones are NGened and not used frequently.
  5. Then the task NGen these assemblies on fly and removes the NGen images not used (This will be known as Reclaiming Native Images Process).
  6. The next time the app runs it gain some boost after it uses the NGened images.


Some notes about Auto NGen process

  • The assembly must targets the .NET Framework 4.5 Beta or later.
  • The Auto NGen runs only on Windows 8
  • For Desktop apps the Auto NGen applies only to GAC assemblies
  • For Metro styles apps Auto NGen applies to all assemblies
  • Auto NGen will not remove not used rooted native images (Images NGened by the developers). Basically the Auto NGen removes only images created by the same process read more about reclaiming native images here.

More Information

Related Posts

Hope this Helps,


Max Number of Threads Per Windows Process

Developers usually thinks that Windows has a default value for the max number of threads a process can hold. while in fact the limitation is due to the amount of address space each thread have can have.

I was working lately on some mass facility simulation applications to test some complex RFID based system. I needed to have a different thread for each person in the facility to simulate parallel and different movement of people at the same time .. and that’s when the fun started Smile.with the simulation running more than 3000 individuals at the same time, it wasn’t too log before I got the OutOfMemory Unfriendly Exception.

When you create new thread, it has some memory in the kernel mode, some memory in the user mode, plus its stack, the limiting factor is usually the stack size. The secret behind that is the default stack size is 1MB and the user-mode address space assigned to the windows process under 32 bit Windows OS is about 2 GB. that allow around 2000 thread per process (2000 * 1MB = 2GB).

Hit The Limit!

imageRunning the following code on my virtual machine with the specs in the image runs around ~ 1400 Threads, the available memory on the machine also takes place in deciding the Max number of threads can be allocated to your process.

Now running the same application multiple times on different machines with different configs will give a close or similar results.

using System;
using System.Collections.Generic;
using System.Threading;

namespace MaxNumberOfThreadsDemo
    public class Program
        private static List<Thread> _threads = new List<Thread>();

        public static void Main(string[] args)
            Console.WriteLine("Creating Threads ...");
            catch (Exception ex)

            Console.WriteLine("Cleanning up Threads ...");


        public static void CreateThreadsWithDefaultStackSize()
            for(int i=0; i< 10000; i++)
                Thread t = new Thread(DoWork);
                t.Name = "Thread_" + i;
                Console.WriteLine(string.Format("{0} started!",t.Name));
        private static  void Cleanup()
            foreach (var thread in _threads)
            _threads = null;

        private static void DoWork()


How Can you extend the Limit?

Well, There are several ways to get around that limit, one way is by setting IMAGE_FILE_LARGE_ADDRESS_AWARE variable that will extend the user mode address space assigned to each process to be 3GB on 32x windows or 4GB on 64x.

Another way is by reducing the stack size of the created thread which will in return increases the maximum number of threads you can create. You can do that in C# by using the overload constructor when creating a new thread and provide maxStackSize.

Thread t = new Thread(DoWork,256);

Beginning with the .NET Framework version 4, only fully trusted code can set maxStackSize to a value that is greater than the default stack size (1 megabyte). If a larger value is specified for maxStackSize when code is running with partial trust, maxStackSize is ignored and the default stack size is used. No exception is thrown. Code at any trust level can set maxStackSize to a value that is less than the default stack size.

Running the following same code after setting the maxStackSize of the created threads to 256KB will increase the number of max threads created per process.


Now If maxStackSize is less than the minimum stack size, the minimum stack size is used. If maxStackSize is not a multiple of the page size, it is rounded to the next larger multiple of the page size. For example, if you are using the .NET Framework version 2.0 on Microsoft Windows Vista, 256KB (262144 bytes) is the minimum stack size, and the page size is 64KB (65536 bytes). according to MSDN.

In closing, resources aren’t free, and working with multiple threads can be really challenging in terms of reliability, stability, and extensibility of your application. but definitely hitting the max number of threads is something you want to think about carefully and consider maybe only in lab or simulation scenarios.

More Information

Hope this Helps,


CLR 4.5: Managed Profile Guided Optimization (MPGO)

Again this performance enhancement (or technology I would say ) is targeting the application startup time more focused on the large desktop mammoth though! the new technology Microsoft introducing with .Net 4.5 is not going to be brand new for you if you are a C++ developer.

The PGO build process in C++

The PGO build process in C++

In C++ shipped with .Net 1.1 a multi-step compilation known as Profile Guided Optimization (PGO) as an optimization technique can be used by the C++ developer to enhance the startup time of the application. by running the application though some common scenarios (exercising your app) with data collection running in the background then used the result of that for optimized compilation of the code. you can read more about PGO here.

As a matter of fact Microsoft has been using this technology since .Net 2.0 to generate optimized ngen-ed assemblies (eating their own dog food) and now they are releasing this technology for you to take advantage of in your own managed applications.

Crash Course to .Net Compilation

In .Net when you compile your managed code it really gets interpreted into another language (IL) and is not compiled to binaries will be running on the production machine, this happen at the run time and referred to as Just-In-Time (JIT) Compilation. The alternative way to that is to pre-compile your code prior to execution at runtime using NGEN tool (shipped with .Net).


Generating these native images to the production processor usually speed up lunch time of the application especially large desktop apps that require a lot of JITting now there are not JIT compilation required at all.

Why you want to use NGen?

If it’s not obvious yet here are some good reasons:

  • NGen typically improves the warm startup time of applications, and sometimes the cold startup time as well
  • NGen also improves the overall memory usage of the system by allowing different processes that use the same assembly to share the corresponding NGen image among them

Exercise your Assemblies!

The Managed Profile Guided Optimization (MPGO) technology can improve the startup and working set (memory usage) of managed applications by optimizing the layout of precompiled native images.By organize the layout of your native image so most frequently called data are located together in a minimal number of disk pages in order to optimize each request for a disk page of image data to include a higher density of useful image data for the running program which in return will reduce the number of page requests from disk. if you think more about it,  mostly it will be useful to machines with mechanical disks but if you have already moved to the Solid State Drive Nirvana the expected performance improvement will probably will be unnoticeable.

How it Works?

As I mentioned before it’s a very similar process to PGO from C++ compiler, where you exercise your assemblies, here are a simplified steps of the process:

  1. Compile and Build your large desktop application to generate the normal IL assemblies.
  2. Run MPGO tool on the IL assemblies built before.
  3. Now exercise a variety of representative user scenarios within your application.(not too little not too much you don’t want the tool be confused about how to organize the layout of your image).
  4. MPGO will store the profile created from your “training” with each IL assembly trained.
  5. Now when you use NGEN tool on the trained assemblies it will genreate an optimized native image.


How to use MPGO

you can find MPGO in the following directory:

C:\program files(x86)\microsoft visual studio 11.0\team tools\performance tools\mpgo.exe

  • Run VS command as administrator and execute MPGO with the correct parameters

MPGO -scenario “c:\profiles\WinApp.exe” -OutDir “C:\profiles\optimized” -AssemblyList “c:\profiles\WinApp.exe”

  • Exercise some most used scenarios on your application. then close the application
  • The IL with profiles will be generated in the output dir
  • Run Ngen on the IL+Profiles

NGEN “C:\profiles\optimized\WinApp.exe”

  • Run the optimized application.

Final Words

MPGO is very cool innovative technology but the results of it depends highly on the human factor, what scenarios you will exercise? and how you’ll run it? the profile gets created so you might end up running it multiple times with different scenarios before your get the expected lunch time you’re looking for.

More Information:

Hope this Helps,


CLR 4.5: Multicore Just-in-Time (JIT)

Well, technically it’s not a new CLR it’s just an update to CLR 4.0 libraries, .Net framework 4.5 will replace your old CLR libraries with a brand new bits but the runtime is technically the same. running a GetSystemVersion() function on .Net 4.0 CLR OR .Net 4.5 CLR gives the same version! “v4.0.30319”


The new CLR takes advantage of the revolution of multicore processor to speed up the application compilation process, since the number of new machines equipped with multicore increased in the last few years more users can benefit from this feature.

The current startup routine for managed apps as depicted blow, the application starts, the the JIT compiler kicks in compiling all the methods into binaries before the program starts to executes. you can see how this can be a very lengthy process for big server applications with tens of dependencies on managed libraries.


.Net 4.5 introduce the concept of Parallel JIT Compilation, where a background thread runs on a separate processor core taking care of the JIT Compilation while the main execution thread running on a different core. In ideal scenario the JIT Compilation thread gets ahead of the main thread execution thread so whenever a method is required it is already Compiled. The question now which methods are required for the startup? in order for the background thread to compile to be ready for a faster startup. That leads us to the new ProfileOptimization type.

Optimization Profilers

This is a new type introduced in .Net 4.5 to improve the startup performance of application domains in applications that require the just-in-time (JIT) compiler by performing background compilation of methods that are likely to be executed, based on profiles created during previous compilations.

Notice ProfileOptimization requires a multicore machine to take advantage of its algorithms otherwise the CLR will ignore it on single core machines.The idea is fairly simple the ProfileOptimization runs in the background of your managed application AppDomain identifying the methods that are likely to be executed at the startup time of the application, so the next time the application runs it uses the profile created from the previous run to optimize the JIT compilation process by compile those methods to be ready when its needed.

The ProfileOptimization can be created simply by setting the profile root directory location (directory must exist!) and then start the profiler and save it to a file. so with two simple methods calls you can create profile files used by your application on the next run for faster startup.


   There are something simple things to understand about the profiler quoted from MSDN

Profile optimization does not change the order in which methods are executed. Methods are not executed on the background thread; if a method is compiled but never called, it is simply not used. If a profile file is corrupt or cannot be written to the specified folder (for example, because the folder does not exist), program execution continues without optimization profiling.

Here’s a quick look of the TestProfile file created by the ProfileOptimization runtime type for the previous sample application.


JIT-compiling using multiple cores is enabled by default in ASP.NET 4.5 and Silverlight 5, so you do not need to do anything to take advantage of this feature. If you want to disable this feature, make the following setting in the Web.config file:


More Information:

Hope this helps,


Visual Debugging Experience in Modern IDEs

Couple of years ago InfoQ wrote about a Java/Eclipse developers tool called Code Bubbles. The idea was simply the current nature of the software development IDEs is really file-based (at least most of it or the most used of it ). and there are no convenient way to create and maintain a simultaneous view of different fragments of the code-base not based on the logical sequencing instead of the file storing the code.

Each bubble is a fully editable and interactive piece of code ( you can think of it as a tiny IDE in a bubble) it can contain a method or group of methods The bubbles exist on a 2-D canvas that represent the current working space.

Code Bubbles: Rethinking the User Interface Paradigm of Integrated Development Environments

A collaboration between Brown University (Where Code Bubbles was born) and Microsoft Research, integrating ideas from Brown University’s Code Bubbles project into Visual Studio result Debugger Canvas as a new power tool for Visual Studio that enable Code Bubbles Like experience, it enable visual debugging experience based on code bubbles on a 2-D canvas which in return I believe it will greatly increase developer productivity and understanding of the code set.

Introducing Debugger Canvas

At the current time of writing Debugger Canvas v1.1 is released to work with Visual Studio 2010 SP1 Ultimate only and the reason according to Microsoft, Debugger Canvas is built on top of Visual Studio Ultimate so that it can re-use the underlying technology for the Dependency Diagrams to identify and display the right fragments on the canvas.

Debugger Canvas offers a great set of features as listed in the website:

  • Switch between Debugger Canvas and file based debugging with a single click, even in the middle of a debug session
  • Debug multiple threads side by side with each thread and its most recent stack frame easily identified
  • Get an overview over recursive calls by showing one bubble per invocation
  • Navigate easily up and down the call stack in the canvas itself
  • Step into methods on a canvas using the debugger
  • Use the normal debugger features in the canvas
  • Share a canvas as an XPS image
  • Take snapshots of local variables so you can make comparisons as you step through code multiple times
  • Add related methods to the canvas using Go to Definition and Find All References

My best feature is the ability to debug multiple threads, the default behavior though is to show only one bubble per canvas for all threads sharing that code, So if you want to be able to see different threads have different executing bubbles even for shared code. The you’ll have to  go to Debugger Options in Visual Studio Options Dialog, you’ll see a new node for Debugger Canvas. Disable the Option “Reuse Bubble when the content is the same”.


Now you can see the same code bubble highlighted with different color indicating a different thread call to the same function.


I’ve been using Debugger Canvas for couple of months now and I find it really fun, amazingly in some situations a little disturbing, especially when the visual canvas gets very cluttered with bubbles and require a lot of scrolling and zooming-in but you can always switch back to the file based view. Nevertheless it’s a great tool I highly recommend especially in sophisticated multithreading algorithms debugging scenarios it helps a lot to understand what is happening, give it a shot.

More Information:

Hope this helps,



Note: This blog post transferred from my OLD BLOG and was originally posted in 2009.

Almost more than 3 years since i’ve been part of projects run by Agile, i had the chance to participate it in different roles and places in the whole project lifecycle,  starting from software engineer passing by being an Architect, Business Analyst, Team leader, and finally a Project Manager. It was absolutely a long journey with good, bad experiences, joyful, sadness, difficult moments, hard situation, stressful situation, and a lot of lessons learned and knowledge gained!Being Agile

Going through my past 3 years i can see clearly the main ideas that made this journey fruity at the end, i can sum up these ideas in the following points:

  1. Don’t walk ever without a goal and a vision to achieve that goal.
  2. Believe in your work, yourself, your vision, and in your colleagues.
  3. Be Smart, Flexible, and Responsible.

Of course Agile is more than that, but i guess on the 2nd level of details, but on the 1st level of main ideas, i think this is what all about Agile!

Working as a team lead and Project Manager in Agile process gave me the chance to observe the whole situation from a higher view, a god view if you like. Also working in long running Agile projects showed me how the process evolve and how people become more familiar and adoptive to it everyday, it gave me the chance to experience and see all the lessons and practices I’ve been reading in Agile books, cause long running projects is a complete life with its ups and downs, failures and success, good persons and bad persons. and if you want you can observe all of that during the long running project.

The past week, i had successfully with my team delivered a 1½ year long project to the customer. summing up the good practices and lessons from this experience lead me to the following list:

  1. Focus on People: They are the constructors in this industry; they are everything, they deserve all the attention! 
    • Share the vision with them clearly and honestly, people perform better when they understand.
    • Build the trust bridge between you and everyone in the team, speak with them individually, listen to their thoughts and complains, take actions when it’s necessary, and if it’s not possible; explain why!
    • People are more important than Processes and Tools! never pay more attention to a tool more than a person in your team.
    • Give them a space to perform, back off and let them finish the work, observe closely the progress but don’t let them feel it. The more the pressure increases in the project the more space you need to give them so they can finish!
    • Show them what goals they are hitting, share the goals achievement lists with them; take with them on group explain what were the goals and what we had achieved; speak with each member individually showing him the goals he needed to achieve, show him what he hit and what he miss!

    1 - Focus on People

    • Be Positive. People are very sensitive to negative emotions, be always positive with them, give them hope and inspiration.
    • Appraise them with any possible facility you got in hand, even if this facility is just some congratulation words.
    • Make a family of your team; get them close to each other. let them set together regularly, work in same location and space, hang out with them.
    • Understand their needs, to be able to motivate them.
    • Celebrate success with them.
  2. Build a Team: 2 - Build a Team
    • Think of a small group of members (5 to 8).
    • Hire the right team members; interview them yourself, test them yourself.
    • Use cross functional team; everyone is working everywhere in the project. 
    • Build the sense of responsibility inside them, learn them how to value their work and care about their final output.
    • Agile teams are self-organized; don’t just select someone in the team to be responsible after you about organizing people; instead teach them how to plan and think of priorities and then leave them to organize themselves.
    • Evaluate team as a unit; don’t just evaluate each member individually also evaluate the whole team as one unit including yourself and share the result with them and think with them where  are the problems and how you can fix it ?
  3. 3 - Be Simple, Be IncrementalBe Simple, Be Incremental: 
    • Start thinking about your system as advanced and huge as you can imagine.
    • Set clear defined goals for you project, and incrementally build it step by step.
    • At your first design focus on solving the project risks as simple as you can.
    • Put extensibility in mind but always remember that simplicity should be in the same equation!
    • Work Iteratively.
  4. Simple Executable, and collective ownership Architecture:
    • Don’t build the system architecture by yourself; instead lead the building process; give everyone in the team the chance to share with his ideas in the design. 4 - Architecture
    • Build Executable Architecture, use small spikes/prototypes to sketch your ideas in code, don’t just sketch ideas on papers.
    • Break down the design into small pieces and allow each one in the team to work on a piece.
    • Use Simple tools (Whiteboards) for communicating your thought and ideas; architectural diagrams and models made for that purpose; teach your team to think and express in visual ways.
    • The more you hear this from your team member “I’ve design this ..”, the more confident you are on the right way cause you had build a collective ownership architecture.
    • Start with simple, exactable, and extensible architecture in project start, and accumulatively enhance and add new feature to your design all the way to project’s end!
  5. Accept Changes All the Time:
    • Avoid defining all requirement at the start of the project! instead try to understand the available requirement.
    • Hunt as much assumption as you can at the start; move your goal from knowing everything to clear unknown points; remember that unresolved assumption become risks during the project constructions!

    5 - Accept Changes

    • Build a clear simple product backlog at the start contains main project decisions and features.
    • Dive deeply in feature’s details at the start of the iteration containing the feature!
    • Accept the fact of changing requirement and priorities and work for it from the beginning!
    • Be honest and advise the customer, customers accept negotiation and sometimes don’t see the clear picture that’s why they ask for changes, be his technical eye and let him feel you are work for his benefit and please do.
  6. Beautiful Code: 6 - Beautiful Code
    • Select a standard way to write the code, the more people from the team involved in choosing this standards the more people comply to it.
    • Emphasize to people why we need to follow standards.
    • Teach them to use comments whenever it’s applicable to be guide on the rood for other colleagues.
    • Enhance and review your standards model as project goes.
    • Use Code Review meetings as a tool to share experiences between team members and enhance the project’s code.
    • Encourage Code Spikes, Pair Programming, TDD, and anyway the team feel it will increase its productivity as long as it will not affect any tradeoffs of the project.
  7. Testing means Done:
    • Having a specialized role in your project for testing is not a bad idea, but making this role responsible for the whole testing process is a bad practice.
    • Everybody including you should be part of the testing process.
    • Testing a feature is required to mark it “Done”; that’s why developer must be involved in testing scenarios.
    • Testers are no less than developers; they are carrying 50% of the product manufacturing.
    • Teach developers how important Unit test for their code as an early safety net to discover issues before functional tests.
    • emphasize the concept of collective ownership for unit tests, anyone changes anywhere needs to makes the previous unit tests green and adds new green unit test for his modifications. 7 - Testing
    • Use different types of tests depending on your project type; but any project should have at least 3 main type of test (a) Unit tests. (b) Functional Test. (c) Acceptance Tests.
    • Everybody in the project should be part of the testing cycle, from the customer (acceptance tests) to developers (unit tests); the more you can involve people in running tests on the project the better quality product you will have at the end.
    • Whenever it’s possible GO for Documented Tests.
  8. Art of Documentation:
    • Fact: No one love writing documents; and no one reads them, but yet there are a very slick slice of docs are important.
    • 8 - Art of DocumentationDon’t make people fill documents that are not important or you know it will not be useful.
    • Show people why this document are useful before they writes it; learn people how to use the project documents instead of asking each others; remind them whenever they use some docs they had wrote before how this docs was helpful for them now.
    • Use visual documents, diagrams, flowcharts, charts, and images.
    • Minimize documentation to the absolute necessary.
    • Everyone owns any document; we are working together, anyone allowed to update in any document as long as there are a good reason and we keep history of the changes.
  9. Smart Process:
    • If you don’t have a process to start with, build a simple one that fits the current environment and people then start enhancing it as projects moves.
    • If you do have a process examine if it fits the current environment and people; make necessary changes then start immediately.
    • Don’t copy processes and rules from books; be smart read what others do and select, develop what you can use of their practices in your current project. 9 - Smart Process
    • Discuss your process with the team; there are always a room for improvement.
    • enhance one practice or activity each phase; don’t make major changes, people hate major changes they don’t believe it will do anything and they take time to adopt to it.
    • Keep your process stable for some time, people need to be comfortable and adoptive with the process before they can share with ideas and enhancements!
    • Forget about Tools, focus about practices.
    • Processes are not written on stones, do changes whenever you feel you need it; be flexible when situations require that.
    • Make your process clear and understandable for everyone in the team; don’t hide anything or use any secret roots in the process.
  10. A Manager for A Project: 10 - A Manager for A Project
    • Be transparent, honest, direct, and positive.
    • Teach people that management is part of the project roles it’s not a higher level or position.
    • Know that “you can Delegate Tasks, but you can’t Delegate Responsibility”; you are always responsible even if it’s not your fault.
    • Responsibility is share between everyone in the team, if one failed we all failed!
    • Smash the manager’s door red lamp; work closely with your team, set next to them, be transparent about your work with them, whenever it’s possible share information about your tasks and work with them, don’t just say i’m busy when you are needed, explain why you are busy.
    • Lead people, Manage Project.
    • Listen to the team, listen to everyone thoughts and complains, build trust between you and people work with you, make them comfortable talking about problems and criticizing anything they want including you!
    • Delegate some of your tasks to team whenever it’s possible, so they can see and feel what kind of work you are working in.

Of course there are more about Agile. I tried to collect the best practices from my last experience in this long project, i though it might be helpful. For myself as i’m turning this page of the past 3 years of my career and looking forward for the new phase of my Agile Career Life, sometimes i think to myself this is my Agile+ Smile

Hope this Helps,